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I.  INTRODUCTION 


A.  BACKGROUND 

In  aviation  squadrons  throughout  the  Navy,  the  maintenanee  department  makes  up 
a  predominant  pereentage  of  the  eommand  as  a  whole.  Within  this  department  are 
numerous  highly  trained  teehnieians  who  play  a  eritieal  role  in  the  operational  readiness 
and  availability  of  the  aireraft  and  systems  for  whieh  they  are  responsible.  It  is  for  this 
very  reason  that  the  management  of  their  training,  career  development  and  assignment  is 
so  vitally  important  within  aviation  squadrons.  Ensuring  that  the  right  people  are 
assigned  to  fill  the  right  billets  so  a  proper  mix  of  experienced  and  not  so  experienced 
technicians  always  exists  is  the  management  goal.  Knowing  how  to  achieve  this  proper 
balance  of  maintenance  expertise  in  a  world  where  tours  of  duty  force  people  to  transfer 
every  two  to  four  years,  and  the  attractiveness  of  civilian  employment  lures  experienced 
technicians  to  leave  the  Navy,  is  one  of  the  biggest  challenges  that  face  manpower 
managers  overall. 

Like  any  organization  that  deals  with  human  resources,  in  order  to  address  the 
challenges  of  managing  personnel,  training,  and  readiness  in  aviation  squadrons,  the 
functions  and  responsibilities  of  a  manpower  manager  were  developed  and  assigned  to 
one  officer  in  the  command.  Today,  the  Assistant  Maintenance  Officer  (AMO)  in  a 
typical  squadron  executes  this  function.  The  AMO  is  normally  an  aviation  ground  officer 
who  is  an  Aerospace  Maintenance  Duty  Officer  (AMDO),  Limited  Duty  Officer  (LDO), 
or  Chief  Warrant  Officer  (CWO).  Lor  most,  their  only  exposure  to  any  sort  of  manpower 
management  education  or  training  occurs  during  aviation  ground  officer  school,  or  AMO 
School  at  Naval  Air  Station  Pensacola,  Llorida.  There,  reference  materials  and 
responsibilities  are  reviewed  and  the  process  of  manpower  management  within  the  Navy 
is  discussed.  As  with  any  education  or  training,  however,  real  insight  and  understanding 
does  not  immediately  occur.  It  is  only  after  some  amount  of  on-the-job  training  and 
working  in  the  fleet  does  one  become  experienced  to  the  point  that  learning  is  reinforced. 
Lor  most  Assistant  Maintenance  Officers,  it  is  said  that  the  manpower  management 
function  can  be  the  most  complex  yet  critical  aspects  of  the  job.  Is  it  not  a  wonder  that  in 
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this  day  and  age  of  the  Information  Revolution  why  manpower  management  remains  as 
time  consuming  and  complex  as  it  does? 

Assistant  Maintenance  Officers  currently  use  paper  copies  of  reports  such  as  the 
Enlisted  Distribution  and  Verification  Report  (EDVR)  and  the  Squadron  Manning 
Document  (SQMD)  or  Activity  Manning  Document  (AMD)  to  reconcile  manning  issues 
and  manage  their  manpower  databases.  Both  reports  are  published  regularly.  The  EDVR 
is  published  monthly  while  the  SQMD/ AMD  is  published  upon  completion  of  an  activity 
Aviation  Manpower  Requirements  Determination  (for  SQMD’s)  or  Shore  Manpower 
Requirements  Determination  (for  AMD’s),  or  as  major  changes  occur. 

Technology  has  changed  over  the  years  and  today  now  allows  users  to  both  view 
and  download  these  documents  via  electronic  means.  Unfortunately,  that  is  the  limit  to 
what  the  manpower  manager  at  the  squadron  level  can  do.  There  exists  no  application  to 
process  data  from  different  databases.  More  so,  the  databases  from  which  these 
documents  are  generated  are  proprietary  systems  that  require  cooperation/authorization 
from  the  highest  levels  of  Eunctional/Type  Commanders  to  update  or  make  changes  to. 

This  thesis  is  a  study  of  an  application  to  address  aspects  of  manpower 
management  functions  by  automating  the  reconciliation  process  between  the  EDVR  and 
the  SQMD/AMD — matching  the  bodies  assigned  to  the  billets  assigned  within  a 
squadron.  The  solution  capitalizes  on  the  use  of  existing  commercial-off-the-shelf 
(COTS)  technologies,  existing  manpower  databases  maintained  within  the  Navy,  and 
automating  a  process  that  is  normally  done  on  paper  with  pen  mark-ups.  This  solution 
merely  addresses  a  portion  of  the  overall  responsibilities  of  the  manpower  manager.  A 
prototype  application  is  also  described  in  this  thesis  that  provides  the  necessary 
functionality  of  such  an  application.  Critical  issues  and  communication  channels  are 
discussed  and  areas  requiring  future  research  are  noted. 

The  future  growth  of  web-based  capabilities  provided  by  the  Navy-Marine  Corps 
Intranet  (NMCI)  and  the  Navy’s  Information  Technology  for  the  2U*  Century  (IT-21) 
infrastructure  may  prove  to  be  a  logical  path  for  manpower  management  to  become 
increasingly  easy  to  use  on  a  more  real  time  basis  resulting  in  more  accurate  manpower 
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management  and  reporting.  Although  the  applieation  presented  in  this  thesis  does  not 
inelude  an  internet  interfaee  and  is  only  prototype  in  nature,  we  foresee  that  an  enterprise- 
scale  development  similar  to  that  discussed  here  is  inevitable —  incorporating  database 
and  web-enabled  tools,  which  presumably  use  the  Internet  as  a  logical  communication 
medium  to  share  data  across  activities,  echelon  commands  and  any  distances  imaginable. 
The  biggest  challenges  manpower  managers  of  today  face  are  education  of  users  and 
managers,  and  acquiring  modern  tools  and  technology  to  meet  increasing  demands  of 
working  more  efficiently  and  intelligently.  The  usefulness  of  a  relational  manpower 
management  database  will  depend  on  whether  the  system  adds  value  to  the  underlying 
activity  manning  data,  and  ultimately,  whether  the  end  user  gains  knowledge  of  the 
overall  readiness  of  their  activity’s  command  and  personnel. 


B,  OBJECTIVES 

Today,  manpower  management  is  a  manual  process.  If  not  done  correctly,  one 
may  rapidly  become  a  spectator  to  the  very  process,  gone  awry,  that  is  supposed  to  be  so 
closely  managed.  What  this  thesis  intends  to  provide  is  one  way  to  greatly  reduce  the 
transaction  costs  and  manual  aspect  of  what  may  be  viewed  as  a  database  management 
problem  with  respect  to  “bodies  and  billets.”  In  our  experience  and  understanding  of 
manpower  management,  we  asked  the  following:  Would  it  be  possible  to  develop  an 
application  that  could  automatically  read  and  import  data  from  an  activity’s  EDVR  and 
compare  it  with  the  standing  SQMD/AMD  at  various  milestone  points  of  a 
deployment/turnaround  cycle  to  produce  a  report  of  overall  T-Ratings  (a  rating  based  on 
an  individual’s  training  level  and  years  of  experience  in  current  Navy  Enlisted 
Classification  (NEC)  Code)  and  M-Ratings  (a  simple  Current  On  Board  (COB)  per 
Billets  Assigned  (BA))  for  individuals  within  the  command?  If  so,  can  the  M-rating  for 
each  Type/Model/Series  and/or  system  be  computed  and  evaluated  automatically?  Could 
a  secure,  internet-based  application  be  developed  for  the  user  to  interface  with  a  central 
database?  Is  it  not  only  possible,  but  also  practical  to  use  a  central,  unified  database  for 
data  input/output,  storage,  processing,  and  archiving  of  data  to  meet  manpower 
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management  requirements  so  that  the  manager  can  make  the  best  decisions  afforded  him 
at  any  given  time? 

Our  objective  in  this  study  has  boiled  down  to  providing  the  manpower  manager 
with  a  more  automated  method  to  reconcile  the  EDVR  and  SQMD/AMD  so  that  the 
AMO  can  focus  more  on  “managemenf’  and  less  on  “processing”  -  something  a 
computer  functions  better  at. 


C.  SCOPE  AND  METHODOLOGY 

1.  Scope 

This  thesis  will  encompass  a  study  of  existing  naval  manpower  COTS 
applications  such  as  Enlisted  Placement  Management  Center’s  (EPMAC)  PC-EDVR,  the 
Wildcat  Navigator  for  EPMAC  telnet,  Total  Eorce  Manpower  Management  System 
(TEMMS),  the  Navy  Training  and  Management  Planning  System  (NTMPS),  and  the 
Citrix  Client  for  NTMPS  database  server  access  and  other  application  interface 
technologies.  Microsoft  Access  is  used  in  this  thesis  as  the  primary  database.  Although 
databases  that  are  more  powerful  exist,  for  the  purpose  of  a  database  within  a  single 
department,  Microsoft  Access  was  found  to  soundly  meet  these  needs.  It  is  also  part  of 
the  Navy’s  IT-21  office  suite  standard  as  well.  This  thesis  will  discuss  areas  of 
deployment  and  reveal  its  benefits  to  manpower  managers  as  well  as  the  shortcomings  of 
the  current  process.  Eurthermore,  it  will  suggest  possible  areas  of  additional  applicability 
beyond  the  initial  implementation  environment.  The  ultimate  goal  of  this  thesis  is  to 
deliver  a  useable  application  and  documentation  that  greatly  increases  efficiency  and 
effectiveness  of  the  manpower  manager,  enables  greater  manpower  knowledge,  and 
simplifies  the  reports  processing  functions. 

2.  Methodology 

The  methods  used  in  this  thesis  research  will  consist  of  the  following  steps: 

1.  Conduct  a  literature  search  of  directives,  instruction,  manuals,  requirements, 
books,  and  other  library  information. 

2.  Interview  current  users  (Squadron  AMO’s)  who  perform  the  manpower 
management  functions. 
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3.  Initiate  and  issue  a  user  questionnaire  to  query  for  user  desires,  requirements, 
and  areas  for  strategic  improvement  in  the  current  manpower  management 
process. 

4.  Conduct  a  thorough  review  of  current  manpower  procedures,  processes,  and 
policies. 

5.  Develop  use  cases. 

6.  Explore  and  contrast  the  various  alternatives  applicable. 

7.  Determine  how  existing  capabilities  provide  managers  with  the  tools  and 
information  to  make  decisions  based  on  current  system  inputs  and  outputs. 

8.  Gather  data  points  via  questionnaires  on  shortfalls  and  strengths  of  the 
existing  system  as  well  as  what  the  ideal  automated  system  might  be. 

9.  Review  current  prototypes  and  utilize  CASE  tools  for  requirements  analysis. 

10.  Utilize  Object  Oriented  Analysis/Design  and  the  Unified  Modeling  Eanguage 
(UME)  to  assist  in  the  determination  of  proper  requirements  and  design  of  the 
thesis. 

1 1 .  Determine  and  utilize  the  proper  productivity  metrics  in  order  to  determine 
existing  performance  levels  compared  to  changes  resulting  from  this  thesis. 

D,  ORGANIZATION  OF  STUDY 

This  chapter  provides  a  background  to  the  importance  of  manpower  management 
and  introduces  the  research  covered  in  this  thesis.  In  Chapter  II,  a  review  of  policies  and 
regulations  is  presented  in  order  to  clearly  illustrate  requirements  set  upon  the  manpower 
manager  and  to  educate  the  reader  to  such. 

Chapter  III  focuses  on  the  research  methods  used.  In  establishing  user  and 
application  requirements  we  met  with  Commander  Tim  Holland,  Command  Strike 
Tighter  Wing  Pacific  (Maintenance  and  Readiness)  acting  and  Eieutenant  Dwayne  Cole, 
Assistant  Maintenance  Officer,  VEA-125.  A  survey  was  also  provided  to  all  squadron 
AMO’s  of  CSEWP  for  input  as  well  via  the  NPS  SPEAR  website. 
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The  name  of  this  prototype  applieation  is  Prometheus,  named  so  after  the 
mythieal  Greek  god  who  taught  humans  various  arts  and  endowed  them  with  the  spark  of 
life  from  the  flame  of  Zeus.  In  its  development,  the  Unified  Modeling  Language  (UML) 
was  utilized  in  requirements  analysis  and  applieation  design.  In  Chapter  III  we  discuss 
our  reasoning,  process,  and  results,  which  are  demonstrated  in  Prometheus. 

Chapter  IV  describes  implementation  issues  such  as  compatibility,  requirements, 
technical  support  and  back-up  issues. 

Chapter  V  addresses  operating  procedures  such  as  training,  maintenance,  and 
documentation. 

Chapter  VI  presents  the  conclusion  by  readdressing  questions  initially  presented 
in  this  research.  Recommendations  are  also  made  to  provide  all  parties  interested  with  a 
potential  solution  to  improving  manpower  management  Navy  wide. 
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II.  LITERATURE  REVIEW  AND  REQUIREMENTS  DEFINITION 


In  this  thesis,  as  with  any  other  project,  in  order  to  more  fully  understand  the 
problem  being  addressed,  an  attempt  to  first  thoroughly  understand  that  problem  must 
take  place.  Prior  to  taking  any  action,  one  has  to  observe,  analyze,  and  make  an 
intelligent  choice  as  to  which  direction  to  head  off,  otherwise  a  great  deal  of  time,  energy 
and  effort  might  all  be  expended  for  no  good  reason.  The  development  cycle  will  then 
need  to  start  again  from  scratch  in  another  attempt  to  “get  it  right”.  To  prevent  this 
wasted  effort,  we  have  decided  to  begin  with  a  review  of  currently  established 
instructions  and  directives  with  respect  to  manpower  management  in  the  Navy. 


A,  EDVR  USERS’  MANUAL 

The  Enlisted  Distribution  and  Verification  Report  Manual  (EDVRMAN)  is  a 
document  published  by  the  Enlisted  Placement  Management  Center  (EPMAC),  New 
Orleans,  Eouisiana.  The  EDVRMAN  publishes  format  and  procedures  for  EDVR 
validation  and  review.  As  stated  on  the  cover  page  of  the  document: 

The  Enlisted  Distribution  and  Verification  Report  Users’  Manual 
(EDVRMAN)  is  the  official  manual  for  interpreting  and  validating  the 
Enlisted  Distribution  and  Verification  Report.  The  EDVRMAN 
supplements  basic  regulation  and  requirements  published  in  references  (a) 
through  (c).  Nothing  in  the  EDVRMAN  shall  be  construed  as 
contravening  or  superseding  other  directives  issued  by  the  Navy 
Department. 


The  EDVRMAN  is  a  document  that  provides  an  in-depth  explanation  of  all  12 
sections  of  the  EDVR.  Within  the  manual,  there  are  numerous  references  to 
“verification”  and  “validation”  of  data  that  are  contained  in  the  EDVR  itself.  “Required 
and  recommended  actions”  are  explained  as  well.  Eor  example,  in  Section  2,  paragraph 
2.2.3,  it  discusses  the  verification  of  the  Distribution  Navy  Enlisted  Classification  (NEC) 
Code.  Although  “the  [EDVR]  system  has  a  built-in  DNEC  to  NEC  inventory 
discrepancy  flag  process”,  the  activity  will  still  need  to  verily  the  NEC’s  of  the 
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prospective  gain  when  alerted  by  the  EDVR  system.  (EDVRMAN,  section  2.2.3) 
Throughout  the  manual,  “Required  and  Recommended  Actions”  for  specific  situations 
are  also  explained.  More  specifically,  in  Section  8,  paragraph  8.5  of  the  EDVRMAN,  the 
crux  of  manpower  management  tasking  is  stated; 

a.  Upon  receipt  of  the  monthly  EDVR,  the  activity  will  verify  actual  NEC 
qualifications  and  the  validity  of  the  assigned  DNEC  of  the  enlisted 
personnel  on  board  in  relation  to: 

(1)  The  NEC  authorized  in  the  Activity  Manpower 
Document  (AMD),  and  its  latest  revision  as  contained  in  EDVR  Section  6. 

(2)  The  individual’s  actual  qualification  against  the 
member’s  field  service  record  and  EDVR  sections  4  and  8. 

b.  If  the  NEC  or  its  principal  is  not  held  in  the  inventory,  three  asterisks 
and  a  numerical  code  (See  Section  2,  paragraph  2.2.3b  for  explanation  of 
these  codes)  will  appear  in  the  INEC  columns  indicating  that  local 
verification  of  the  member’s  qualification  in  accordance  with  Volume  II  of 
the  Manual  of  Navy  Enlisted  Classification  Standards  (NEC  Manual) 
NAVPERS  18068E  is  necessary  and  the  command  is  required  to  take  the 
following  actions  to  correct  the  discrepancy. . . 


Easily,  in  Section  15  of  the  EDVRMAN,  a  decision  logic  table  listing  events, 
actions,  references,  and  remarks  can  be  found  which  greatly  helps  to  guide  the  EDVR 
reviewer  in  the  necessary  direction  to  resolve  questions  or  concerns.  An  extract  of  this 
table  is  located  in  Appendix  A  of  this  thesis.  The  EDVRMAN  is  an  important  document 
because  “manning  and  assignment  decisions  are  based  on  information  contained  in  the 
EDVR.  It  is  extremely  important  that  each  activity  keep  its  account  up-to-date  and 
accurate  by  reporting  personnel  events  as  they  occur  and  correcting  errors  when 
identified.”  (EDVRMAN,  section  1.4) 


B.  COMPUTERIZED  SELF  EVALUATION  CHECKLIST  (CSEC) 

The  Computerized  Self  Evaluation  Checklist  (CSEC)  is  a  document  published  by 
Naval  Air  Systems  Command  (AIR  3. 2D),  as  a  tool  for  ensuring  that  aviation  commands 
are  managing  all  programs  required  of  the  Naval  Aviation  Maintenance  Program 
(NAMP),  OPNAVINST  4790.2  in  a  standardized  manner.  There  are  26  programs 
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dictated  in  the  NAMP,  of  whieh  Manpower  Management  is  one.  In  the  CSEC,  there  is  an 
area  eheeklist  for  Manpower  Management.  The  following  questions,  14  in  all,  taken 
from  the  eheeklist  have  also  been  eonsidered  requirements  for  this  thesis  sinee  it  is  from 
this  checklist  that  the  Type  Commander  Aviation  Maintenance  Management  Team 
(AMMT)  will  evaluate  a  squadron. 


NUMBER _ QUESTION _ 

280 1C  Is  the  Manual  of  Navy  Total  Eoree  Manpower  Policies  and  Proeedures 

(OPNAVINST  1000. 16J)  utilized  by  all  echelons  in  dealing  with 
manpower  change  requests  or  other  manning  issues?  Ref.  OPNAVINST 
4790. 2H,  vol.  I,  par.  2.4e 

2802C  Is  the  AMD  reviewed  biennially  (every  two  years)  by  the  Manpower 

Manager?  Refs.  OPNAVINST  4790.2H,  vol.  I,  par.  2.4e  and 
OPVANINST  1000.16J,  par.  8.15.a 

2803C  Is  each  publishing  of  the  EDVR  reviewed  for  aecurate  and  up  to  date 

information?  Refs.  OPNAVINST  4790. 2H,  vol.  V,  par.  2.3e(12); 
EDVRMAN,  par.  1.4;  andNAVPERS  15909P,  par.  1.032 

2804C  Are  AMD  (Activity  Manning  Documents)  ehange  requests  submitted 

whenever  ehanges  are  requested?  Refs.  OPNAVINST  4790.2H,  vol.  I,  par. 
2.4c  and  OPNAVINST  1000.16J,  par.  1003.1 

2805C  Are  DNEC  Change  Requests  submitted  to  EPMAC  for  personnel  whose 
DNECs  are  incorrect  or  for  personnel  who  obtain  NECs  eurrently  listed  on 
Manpower  Authorization,  but  are  unfilled?  Refs.  OPNAVINST  4790. 2H, 
vol.  I,  par.  2.4e  and  EDVRMAN,  secs.  8.3.2e,  8.5. Id  and  8.5.2 

2806C  Are  appropriate  personnel  doeuments  (EDVR,  AMD  and  standard  transfer 

direetives)  monitored  to  ensure  personnel  assigned  already  possess  the 
requisite  skills,  or  will  receive  training  prior  to  arrival,  eommensurate  with 
the  billet/DNEC?  Ref  OPNAVINST  4790.2H,  vol.  V,  par.  2.3e(12) 

2807C  Are  maintenance  personnel  working  in  the  billets  assigned  (DNEC)  on  the 

EDVR?  Refs.  OPNAVINST  4790.2H,  vol.  I,  par.  2.4e  and  EDVRMAN, 
par.  8.5.2 

2809C  When  eritical  manning  shortages  (ineluding  NECs)  are  identified,  is  an 

Enlisted  Manning  Inquiry  Report  (EMIR)  submitted  to  EPMAC?  Ref 
OPNAVINST  4790.2H,  vol.  I,  par.  11.2.2b(6)  and  NAVPERS  15909P 
(ENETRANSMAN),  oh.  26.02 

28 IOC  Are  messages  forwarded  to  EPMAC  requesting  PRD  adjustments  on 

personnel  that  are  separated  prior  to  their  PRD?  Ref  OPNAVINST 
4790.2H,  vol.  I,  par.  11.2.2b(6)  andNAVPERS  15909E,  par.  3.063 
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281 1C  Does  the  AMO  determine  the  apportionment  of  maintenanee  personnel  to 

the  department  and  monitor/eoordinate  the  assignment  of  TAD  personnel? 
Ref  OPNAVINST  4790.2H,  vol.  1,  par  1 1.2.2b(7) 

2813C  Are  NEC  diserepaneies  in  the  eommand’s  Aetivity  Manpower  Doeument 

eorreeted?  Refs.  OPNAVINST  4790.2H,  vol.  I,  par.  2.4;  EDVRMAN,  see. 
8.5. Id;  and  OPNAVINST  1000. 16J,  par.  1003 

2814C  Are  diserepaneies  in  an  individual’s  NEC  qualifieation(s)  (loss  of  required 

qualifieation/eertifieation/profieieney,  ete.)  eorreeted  by  submitting  a 
NACPERS  1221/1  or  by  eompleting  the  NEC  Diserepaney  Report?  Ref. 
OPNAVINST  4790.2H,  vol.  I,  par.  1 1.2.2b(6)  and  EDVRMAN,  see.  8.5. Id 

2815C  Does  the  aetivity  maintain  a  eurrent  organizational  roster  board,  automated 

or  manual,  whieh  ineludes  as  a  minimum,  name,  rate  and  billet  assignment 
in  eonjunetion  with  the  AMD?  Ref.  OPNAVINST  4790.2H,  vol.  I,  par. 
11.4.b(12) 

2816C  Are  individual  NEC  qualifieations  validated  against  assigned  DNECs? 

Ref  OPNAVINST  4790.2H,  vol.  I,  par.  11.2.2b(6)  and  EDVRMAN,  see 
8.5 

C.  OPNAVINST  1000.16J  (MANPOWER  MANUAL) 

The  Manual  of  Navy  Total  Eoree  Manpower  Polieies  and  Proeedures  instruetion, 
OPNAVINST  1000. 16J,  is  a  doeument  issued  by  the  Offiee  of  the  Chief  of  Naval 
Operations.  This  instruetion  is  the  governing  doeument  from  whieh  subordinate 
eommands  delineate  additional  manpower  requirements  for  their  speeifie  funetions  and 
applieations.  The  purpose  of  the  doeument  is  to  “provide  poliey  guidanee  and  proeedures 
to  develop,  review,  approve,  and  implement  total  foree  manpower  requirements  and 
authorizations  for  naval  aetivities”.  (OPNAVINST  1000. 16J,  seen,  l.a)  It  also  assigns 
management  responsibilities  and  details  manpower  proeedures  for  determining 
manpower  requirements  and  authorizations.  This  doeument  also  establishes  manpower 
requirements  through  several  programs  designed  for  all  eomponents  of  the  Navy.  The 
program  speoifieally  used  for  squadron  manpower  requirements  is  the  Aviation 
Manpower  Requirements  Determination  Program  for  Squadron  Manpower  Doeuments 
(SQMD’s),  earrier  air  wings  (CVW’s),  and  afloat  aireraft  intermediate  maintenanee 
departments  (AIMD’s). 
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First,  an  understanding  of  manpower  requirements  should  be  taken  from  the 
instruetion.  As  stated  in  seetion  4. a  (2): 

Manpower  requirements  shall  be  based  on  directed  mission,  functions,  and 
tasks  (MFT’s)  and/or  required  operational  capability/projected  operational 
environment  (ROC/POE)  and  reflected  on  the  Activity  Manpower 
Document  (AMD).  Workload  shall  be  determined  using  industrial 
engineering  or  other  justifiable  techniques  that  yield  accurate  manpower 
requirements. 


Also,  as  stated  in  section  200.5; 

The  ROC/POE  is  the  most  critical  element  in  developing  manpower 
documents.  The  ROC  provides  a  precise  definition  of  the  unit’s  mission 
statement.  The  POE  is  a  description  of  the  specific  operating  environment 
in  which  the  unit  is  expected  to  operate. 


In  section  4. a  (3): 

Manpower  requirements  shall  reflect  the  minimum  quantity  and  quality  of 
manpower  required  for  peacetime  and  wartime  to  effectively  and 
efficiently  accomplish  the  activity’s  mission.  Military  quality  information 
includes  designator/paygrade,  rating/rate,  subspecialty  (SUBSP), 
Additional  Qualification  Designation  (AQD)  and  Navy  Enlisted 
Classification  (NEC)  codes. 


Responsibility  for  the  Aviation  Manpower  Requirements  Determination  Program 
is  assigned  to  Navy  Manpower  Analysis  Center  (NAVMAC)  for  the  development  and 
documentation  of  total  force  manpower  requirements  for  all  fleet  activities. 
(OPNAVINST  1000.16J,  seen.  4.b) 

In  section  5,  manpower  management  is  defined  as  “the  methodical  process  of 
determining,  validating,  and  using  manpower  requirements  and  active  duty  MPN/RPN 
manpower  authorizations  and  end  strength.” 

Eastly,  the  Activity  Manning  Document  is  described  and  defined  in  Chapter  10  of 
enclosure  (I): 

Manpower  requirements  are  initially  published  in  draft  SMDs,  EMDs, 

SQMDs,  and  SEAOPDET  manpower  documents.  Once  the  review  cycle 
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is  complete,  CNO  (N12)  will  direet  ehanges  aecordingly  and  NAVMAC 
will  produee  and  upload  a  final  SMD,  FMD,  SQMD,  or  SEOPDET 
manpower  doeument  into  TEMMS.  Subsequently,  an  AMD  will  be 
available  from  TEMMS  and  will  serve  as  the  single  source  for  manpower 
requirements  and  authorizations  data.  The  AMD  displays  a  eomplete 
pieture  of  total  foree  manpower  requirements  as  they  change  aeross  the 
Euture  Years  Defense  Plan.  (OPNAVINST  1000. 16J,  Enel.  (1),  Ch.  2, 
seen  200.2) 


The  SQMD  that  is  processed  and  ultimately  ends  up  as  an  AMD  in  TEMMS  is  the 
direct  input  tool  for  a  command  to  affect  changes  to  its  manpower.  It  is  for  this  reason 
that  the  squadron  AMO  must  have  a  through  understanding  of  eommand  manning  as  well 
as  all  information  (e.g.  NEC,  experienee  level,  PRD,  EAOS,  ete.)  pertaining  to  the 
members  of  the  department.  Additionally,  ehanges  to  the  SQMD  may  be  required  if  there 
are  ehanges  in  the  assigned  aireraft,  flight  hour  utilization  rates,  fleet  replaeement 
squadron  (ERS)  student  throughput,  ERS  eurriculum,  eorreetive  maintenanee  model,  and 
major  ehanges  in  mission,  foree  structure,  or  fleet  issues.  (OPNAVINST  1000. 16J,  Enel. 
(1),  Ch.  2,  seen.  202.3)  Additionally,  enclosure  (1),  seetion  203.2  lists  SQMD  manpower 
doeument  development  elements. 


D,  TOTAL  FORCE  MANPOWER  MANAGEMENT  SYSTEM  (TEMMS) 

The  Total  Eoree  Manpower  Management  System  (TEMMS)  is  the  single 
authoritative  database  for  total  foree  manpower  requirements  and  aetive  duty  MPN/RPN 
(Manpower  and  Personnel,  Navy/Reserve  Personnel,  Navy)  manpower  authorizations  and 
end  strength.  A  manpower  authorization  eannot  exist  without  a  valid  manpower 
requirement  doeumented  in  TEMMS. 

TEMMS  is  an  information  system  designed  to  support  Deputy  Chief  of 
Naval  Operations  (M&P)  (Nl)  by  providing  a  single,  authoritative  souree 
for  manpower  data.  Eoeated  on  a  mainframe  eomputer,  this  data  ineludes 
manpower  requirements,  whieh  manpower  requirements  are  authorized 
(funded),  and  the  resourees  used  to  authorize  the  requirement.  TEMMS 
allows  the  ability  to  traek  manpower  for  the  aetive  military  (offieer  and 
enlisted),  reserve  military,  civilians,  contractors,  and  other  eategories  of 
manpower  (e.g.,  other  military  services).  TEMMS  provides  aeeess  to 
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current  data,  and  storage  and  retrieval  of  historieal  data  for  resource 
sponsors,  manpower  elaimants,  SMC’s  and  other  management  information 
users.  Additional  information  and  proeedures  ean  be  found  in  [the  Total 
Force  Manpower  Management  System  (TFMMS)  Users’  Manual], 
(OPNAVINST  1000.16J,  seen.  900.1) 


In  addition  to  the  eentral  database  used  for  housing  manpower  data,  an  applieation 
also  exists  for  manpower  users  to  interfaee  with  the  database;  however,  aeeess  is  limited 
to  manpower  personnel  at  the  SMC  level  and  above  -  a  elassifieation  level  that  the 
squadron  AMO  is  not  granted.  The  TFMMS  Miero  Manpower  Change  Applieation 
(TMMCA)  is  a: 

...software  paekage  for  [a]  personal  eomputer  that  allows  manpower 
managers  to  initiate  AMD  Change  Requests,  provide  AMD  and  end 
strength  information,  reports,  and  summaries.  By  using  the  TFMMS 
mainframe  eomputer,  TMMCA  ean  be  used  to  download  a  speeifie 
aetivity’s  or  the  entire  manpower  elaimant’s  and/or  SMC’s  AMD  and  end 
strength.  The  AMD  and  end  strength  ean  be  eopied  and  used  on  a  PC  for 
other  TMMCA  users  to  create  AMD  Change  Requests  and/or  query 
reports.  (OPNAVINST  1000. 16J,  seen.  901. 1) 


This  applieation  is  not  used  at  the  squadron  level,  but  is  used  at  the  Wing  level. 
Squadron  AMO’s  must  eoordinate  with  the  Wing  manpower  manager  for  aeeess/reports 
utilizing  TMMCA. 


E.  DISCUSSIONS  WITH  CSFWP  (MAINTENANCE  AND  READINESS) 

The  idea  of  this  thesis  first  oecurred  in  the  Fall  of  2001  when,  in  our  seareh  for  a 
database-related  topie,  we  were  given  an  opportunity  to  speak  with  the  aeting 
Commander  Strike  Fighter  Wing  Paeific  (CSFWP)  Maintenance  Offieer,  Commander 
Tim  Holland.  Our  first  discussions  with  him  were  primarily  via  e-mail  regarding  the 
development  of  an  applieation  to  report  the  training  level  of  a  squadron,  or  T-Rating  as  it 
is  normally  ealled,  in  a  manner  that  would  be  easy  to  display,  ealeulate,  and  brief  to 
others.  Commander  Holland,  who  had  been  working  on  a  solution  to  this  himself, 
presented  to  us  the  idea  that  an  aetivity  utilize  an  applieation  to  import  fields  from  their 
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EDVR/AMD,  manually  or  automatically,  enter  the  T-Rating  for  eaeh  individual  at  a 
number  of  points  (projeeting  for  the  future  as  well  based  on  present  data)  then  evaluate 
the  matrix  to  determine/ealculate  the  overall  T-Rating.  Ideally  it  would  evaluate  values  at 
the  following  points  in  the  deployment  training  eyele:  1)  Now,  2)  TSTA,  3)  CTX,  4) 
Fallon,  5)  JTFX  and  6)  Deployment  Day  ONF.  His  comments  became  the  essence  of  the 
first  objective  of  this  thesis.  This  greatly  contributed  to  making  the  definition  of  the 
problem  clear.  In  one  e-mail  from  CDR  Holland  he  stated; 

A  very  sophisticated  program  would  simply  read  the  FDVR/AMD  direetly 
and  evaluate  the  M  and  T  ratings.  The  idea  is  to  identify  early  weak  areas 
and  get  training  or  bodies  and  training  to  fix  the  problem.  The  tool  must 
have  the  ability  to  do  ‘what  if  scenarios  and  be  simple  to  use  by  non¬ 
computer  folks.  Most  JO’s  today  can  easily  use  Excel.  Aeeess  is  a  bit 
problematic  but  with  proper  menus  and  utilities  would  work.  (Holland,  e- 
mail  dated  llOCTOl) 


This  beeame  the  first  requirement,  whieh  we  set  out  to  analyze,  and  CSFWP 
Maintenance  became  the  primary  customer.  It  was  during  this  analysis  period  when  we 
concluded  that  the  solution  we  sought  was  more  likely  a  product  of  the  squadron 
Assistant  Maintenance  Officers’  manpower  management  process. 


We  began  our  definition  phase  by  deeiding  to  foeus  first  on  the  T-Rating  instead 
of  the  M-Rating,  as  it  was  the  more  complex  of  the  two.  The  CSFWP  MO  specifically 
detailed  what  data  fields  were  required  as  input  in  the  calculations  of  the  T-Rating. 
Depieted  in  Figure  1  below  is  a  sample  report  of  the  fields  used. 


Unit 

BSC 

BHEC 

Rate 

Rank 

BA 

COB 

NEC  Date  EDA/L  HEC1 

NEC2 

EDVR 

Date 

Aircraft  Area 

Core 

40010 

0- 

1 

Nov-01 

FA-18C 

Core 

40015 

0- 

1 

Nov-01 

FA-18C 

Core 

40020 

ABCM 

E-9 

1 

0 

Nov-01 

FA-18C 

Core 

40025 

AMEC 

E-7 

1 

1 

1  -Aug-00  9-Apr-OO 

Nov-01 

FA-18C  Other 

Core 

40030 

AMI 

E-6 

1 

1 

1 -Nov-99  9-Apr-OO  8342 

Nov-01 

FA-18C  Other 

Core 

40035 

AE2 

E-5 

1 

1 

1 -Nov-00  PL  0207  7131 

7133 

Nov-01 

FA-18C  Elec/lnst 

Core 

40040 

AM2 

E-5 

1 

1 

1  -Apr-01  9-Apr-OO 

Nov-01 

FA-18C  Hyd 

Core 

40045 

AM3 

E-4 

1 

1 

1 -Mar-00  9-Apr-OO  7232 

Nov-01 

FA-18C  Airframe 

Core 

40050 

AEC 

E-7 

1 

1 

1 -Apr-00  9-Apr-OO  0  9526 

Nov-01 

FA-18C  FUR 

Core 

40105 

0- 

1 

1 

Nov-01 

FA-18C 

Core 

40120 

AZCS 

E-8 

1 

1 

1  -Jun-OO  9-Apr-OO  0 

9502 

Nov-01 

FA-18C  Other 

Figure  1 .  Activity  T-Rating  Input  Report 
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Almost  all  the  data  contained  in  this  report  is  pulled  from  other  reports, 
specifically  from  each  squadron’s  EDVR  and  SQMD.  There  is  one  area  where  the 
AMO’s  input  and  logic  are  involved  though  -  the  assignment  of  “area”.  This  is  the  area 
in  the  squadron  to  which  the  member  is  assigned  for  duty  within  the  department.  This  is 
not  data  already  published  in  any  document,  nor  is  it  static.  The  AMO  could  change  this 
area  assignment  periodically.  The  data  from  this  report  is  then  used  to  compile  an  overall 
activity  report  as  illustrated  below  in  Figure  2. 


“H“ 


“T 


Training 


AIMD  Lemoore 


me  Hidraulic 

ALSS 

EnofAPU 

CSDfGen 

Elecflnst 

Controls  8 

Dlsplags 

Com/Nav 

RADAR 

1  ECM 

Recce 

FLIR 

FCS 

Weapons 

GSE& 

Other 

1  Awg  1 

2.82 

3.15 

3.03 

3.05 

3.18 

3.18 

3.08 

3.24 

3.00 

3.00 

3.04 

3.00 

3.08 

3.36 

2.82 

3.15 

3.03 

3.05 

3.18 

3.18 

3.08 

3.24 

3.00 

3.00 

3.04 

3.00 

3.08 

3.36 

2.82 

3.15 

3.03 

3.05 

3.18 

3.18 

3.08 

3.24 

3.00 

3.00 

3.04 

3.00 

3.08 

3.36 

2.82 

3.15 

3.03 

3.05 

3.18 

3.18 

3.08 

3.24 

3.00 

3.00 

3.04 

3.00 

3.08 

3.36 

2.82 

3.15 

3.03 

3.05 

3.18 

3.18 

3.08 

3.24 

3.00 

3.00 

3.04 

3.00 

3.08 

3.36 

2.82 

3.15 

3.03 

3.05 

3.18 

3.18 

3.08 

3.24 

3.00 

3.00 

3.04 

3.00 

3.08 

3.36 

2.82 

3.15 

3.03 

3.05 

3.18 

3.18 

3.08 

3.24 

3.00 

3.00 

3.04 

3.00 

3.08 

3.36 

2.82 

3.15 

3.03 

3.05 

3.18 

3.16 

3.08 

3.24 

3.00 

3.00 

3.04 

3.00 

3.08 

3.36 

2.82 

3.15 

3.03 

3.05 

3.18 

3.16 

3.08 

3.24 

3.00 

3.00 

3.04 

3.00 

3.08 

3.36 

2.82 

3.15 

3.03 

3.05 

3.18 

3.16 

3.08 

3.24 

3.00 

3.00 

3.04 

3.00 

3.08 

3.36 

Average 

Lowest 


All 

All 


Rate 

Paggrade 


Rqmt  is  T-2 


COB  T-Rating 


3.07 

3.24 


Expert  BOH :  NEC  *  2  Years  experience. 
Journeyman  :  NEC  •  6  Months  experience. 

Apprentice  s  NEC  awarded. 

Untrained  s  Wrong  or  no  NEC  for  required  billet. 


s  average  of  T-ratings 
:  lowest  value  of  each  area. 


U  pdate 


Figure  2.  Monthly  Activity  T-Rating 


From  the  discussions  with  the  CSFWP  MO,  we  were  able  to  more  clearly  define 
the  problem  as  a  database  situation  where  data  from  multiple  databases  needed  to  be 
aggregated  and  reported  frrst,  so  that  a  calculation  could  be  performed  resulting  in  a 
rating  that  could  be  reported  and  displayed  in  a  number  of  ways.  The  product  of  such  an 
automated  process  could  also  be  a  feeder  to  the  monthly  Status  of  Readiness  and  Training 
System  (SORTS)  reports.  We  concluded  that  we  would  pursue  an  application  that  would 
automatically  assess  the  existing  training  and  readiness  of  an  activity  based  on  its  EDVR 
and  AMD. 


15 


F.  SURVEY  FOR  REQUIREMENTS  AND  FINDINGS 

Within  CSFWP,  there  are  17  squadrons.  Of  these,  many  were  not  at  NAS 
Lemoore,  CA  during  the  times  we  were  able  to  visit  there.  In  our  attempts  to  reaeh  as 
many  AMO’s  as  possible,  and  in  eoordination  with  the  Wing  AMO,  an  invitation  to 
partieipate  in  an  on-line  survey  was  given  to  all  wing  AMO’s.  The  survey  was  titled 
AMO  Manpower  Survey  and  was  located  at  the  following  URL: 
http://www.nps.navv.mil/spear/survevs/amomanpower.htm.  This  survey  was  active  from 
June  2002  until  August  2002.  Following  are  questions  (Q’s)  that  were  used  to  poll 
AMO’s  for  their  input  regarding  requirements  for  an  automated  manpower  application 
and  the  responses  (R’s)  received: 

Ql.  What  factors  do  you,  the  manpower  manager,  consider  most  important  in 
performing  this  aspect  of  your  job. 

Rl.  RIS  runs  and  the  SQMD  (soon  to  be  F/A-18F  AMD  once  finalized) 

R2.  Walking  the  beat,  contacting  EPMAC  and  SUPERS.  Trips  to  same.  The 
ARIS,  and  NTMPS  (which  you  still  can't  get  on  NMCl). 

R3.  The  ability  to  look  at  near-real  time  data  on  the  number  of  incoming  and 
outgoing  personnel  in  order  to  report  accurately  the  readiness  with  regards  to 
manpower,  training  and  NEC  management 

Q2.  In  what  areas  of  manpower  management  do  you  feel  you  need  help  more 
than  others? 

Rl .  The  continuity  between  what  EPMAC-BUPERS  and  NAVMAC  are  able  to 
see.  1  believe  there  should  be  "one-stop-shopping"  when  it  comes  to 
manpower  and  the  assessment  of  where  you  are  as  an  activity. 

R2.  AMD’s  and  SQMD's  need  to  be  more  precise.  1  don't  need  mission  NEC's. 
Give  me  the  baby,  not  the  labor  pains. 

R3.  The  ability  to  capture  data  from  various  sources. 

Q3.  In  performing  the  manpower  management  functions  of  your  job,  how  do  you 

assess  the  T-Rating  for  your  department  now? 
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R1 .  I  take  the  number  of  billets  with  an  NEC  attaehed  to  it  and  plug  the  personnel 
within  the  department  into  those  billets  and  assess  the  shortages  or  overages 
of  eaeh  rate  for  the  particular  NEC. 

R2.  Don’t  know 

R3.  Through  the  use  of  SORTS  software  from  OPS 

Q4.  Do  training  issues,  with  respect  to  generating  a  T-Rating  report,  for  your 
department,  exist?  If  so,  which  aspects  are  most  challenging  to  you? 

R1 .  no  response 

R2.  Mainly  for  OP's. 

R3.  Collecting  and  disseminating  the  data. 

Q5.  How  do  you  assess  Manning  levels  for  your  department  now? 

R1 .  I  take  the  POB-9  and  divide  it  by  the  M+1  for  each  particular  rate  area  and 
derive  a  percentage.  Then  I  perform  the  same  math  for  the  overall 
maintenance  department.  As  far  as  the  SORTS  for  each  mission  area,  OPS 
provides  the  "T"  of  the  T&  R  matrix  and  I  provide  manning  numbers  for  the 
SORTS  report 

R2.  No  response 

R3.  Through  ED VR,  ARIS 

Q6.  What  format  of  the  EDVR  do  you  use? 

R1 .  Paper  copy 

R2.  Paper  copy.  EEECTRONIC  COPY  UNREADABEE  (EIGHT  GREY) 

R3.  Paper  copy 

Q7.  How  do  you  receive  the  monthly  EDVR? 

R1 .  Personnel  Department  copy  of  the  downloaded  document 

R2.  Downloaded  from  EPMAC 
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R3.  Electronic  file  located  on  command  LAN 

Q8.  In  your  opinion,  what  would  be  the  ideal  way  to  receive  the  EDVR? 

R1 .  Electronically  via  the  Web 

R2.  There  should  be  a  real-time,  web-based  EDVR  which  is  easier  to  read  than 
the  current  PC-EDVR.  Should  have  access  to  detailers'  database,  which 
projects  fiirther  out  than  EDVR. 

R3.  E-mail  to  admin,  so  they  can  e-mail  me  the  sections  I  desire. 

Q9.  How  do  you  receive  the  command  Manning  Document  (SQMD/AMD)? 

Rl.  Electronic  file  is  e-mailed  to  you;  WORD  format,  needs  to  be  Excel 
R2.  CDEWP  forwards  electronic  copy 
R3.  Squadron  doesn't  have  one  yet 

QIO.  In  your  opinion,  what  would  be  the  ideal  way  of  receiving  the  Manning 
Document? 

Rl .  Electronically  in  Excel  format 

R2.  E-mailed  automatically  to  commands  as  soon  as  available. 

R3.  Same  as  EDVR 

Qll.  Are  you  familiar  with  the  T-Rating  CDR  Holland  was  developing  while 
acting  as  CSEWP  Wing  MO? 

Rl.  no 

R2.  no 

R3.  no 

Q12.  If  yes  to  above  question,  please  elaborate  some  on  what  you  thought  its 
Strengths  and  Weaknesses  were. 

Rl-3.  All  responses  N/A. 

Q13.  Would  more  directions/instructions  be  desirable  for  this  type  of  application? 


18 


Rl-3.  All  responses  N/A. 

Q14.  At  what  time  periods  is  data  input  to  your  Manning  Database? 

Rl.  Weekly 
R2.  Daily 
R3.  Monthly 

Q15.  At  what  time  periods  is  the  data  output?  (i.e.  to  reports,  arehive  fdes,  other 
databases,  ete.) 

Rl.  Weekly 

R2.  Weekly 

R3.  As  changes  occur 

Q16.  At  what  time  periods  are  reports  written? 

Rl.  Monthly 
R2.  Weekly 
R3.  As  required 

Q17.  How  many  transactions  do  you  process  per  month  in  you  Manpower 
Database? 

Rl.  25 

R2.  26-50 

R3.  0-10 

Q18.  What  should  a  manpower  application  be  able  to  do  for  you  in  order  to  be 
considered  a  functional  program? 

Rl .  Be  input  and  sorted  in  Excel 

R2.  Needs  to  project  future  manning  based  upon  current  information.  Needs  to 
present  data  in  various  forms,  and  be  capable  of  generating  outputs  that  can 
be  designed  by  the  user. 
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R3.  Don’t  know 


Q19.  How  much  experience  do  you  have  with  Mierosoft  Exeel? 

Rl.  Very  mueh 

R2.  Very  mueh 

R3.  Very  little 

Q20.  How  much  experience  do  you  have  with  Mierosoft  Access? 

Rl.  Some 

R2.  Very  mueh 

R3.  None 

Q21 .  Please  list  references  used/found  useful  regarding  Manpower  Management. 

Rl.  NTMPS  -  SQMD  -  OPNAV  1000. 16J  -  ROC/POE 

R2.  EDVRMAN 

R3.  Nothing  that  gives  a  brand  new  AMO  a  elue. 

Q22.  Please  provide  your  contact  information  so  that  we  may  get  back  with  you. 

Survey  Comments: 

R3.  EDVR  needs  to  be  replaeed  with  a  superior,  real-time  produet. 

G.  SUMMARY 

Requirements  definition  ean  probably  be  stated  as  being  the  most  eritieal  step  of 
requirements  analysis.  Gaining  a  better  understanding  of  what  the  issues  are  and  how 
they  are  structured  into  the  customer’s  business  praetices  has  been  the  goal  of  our 
requirements  analysis  in  this  study.  In  this  particular  instance;  however,  there  are  not 
only  the  users’  ideas  of  how  the  business  practices  occur,  but  there  are  also  instruetions 
and  directives  that  dietate  speeifie  actions  and  responsibilities.  It  is  for  this  reason  that 
we  have  eonsidered  many  of  these  doeuments,  sueh  as  the  Computerized  Self  Evaluation 
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Checklist,  as  additional  requirements  of  what  a  system  must  satisfy,  and  why  we  have 
reviewed  them  here  in  this  chapter. 

Chapter  III  will  further  expound  on  the  results  of  this  chapter,  and  then  go  further 
into  an  analysis  of  the  requirements  for  our  development.  From  this,  we  start  the  design 
and  lastly  development  of  the  solution,  which  we  are  proposing  in  this  thesis 


21 


THIS  PAGE  INTENTIONALLY  LEET  BLANK. 


22 


III.  RESEARCH  METHOD 


A.  MODELING  UTILIZING  THE  UNIFIED  MODELING  LANGUAGE 

(UML) 

1.  Plan  and  Elaborate  Phase 

For  this  study,  an  Object  Oriented  Analysis  and  Design  (OOA&D)  methodology 
was  used  to  identify  system  requirements.  As  opposed  to  a  functional  approach,  an 
Object  Oriented  approach  is  taken  to  analyze  the  results  of  the  requirements  definition. 
To  construct  and  present  concepts  and  their  relations,  the  Unified  Modeling  Language 
(UML)  was  used.  From  the  software  development  aspect,  the  UML  best  standardizes 
representations  and  terminology  as  well  as  the  steps  of  the  development  process.  The 
requirements  analysis  product  within  this  chapter  has  been  produced  using  methods 
discussed  in  the  textbook  Applying  UML  And  Patterns;  An  Introduction  To  Object 
Oriented  Analysis  and  Design,  by  Craig  Larman.  Many  of  the  figures  and  diagrams  have 
been  modeled  in  the  Larman  textbook  style. 

The  ultimate  goal  of  object  oriented  analysis  and  design  utilizing  the  unified 
modeling  language  is  “finding  and  describing  objects  or  concepts  in  the  problem  domain” 
and  “defining  logical  software  objects  that  will  ultimately  be  implemented  in  an  object 
oriented  programming  language”  such  as  UML.  (Larman,  p.  6) 

Within  OOA&D,  although  no  structured  process  is  prescribed,  we  have  defined 
our  development  process  as  such:  1)  Plan  and  Elaborate  Phase,  2)  Analyze  Phase,  3) 
Design  Phase,  and  4)  Construct  Phase.  The  development  process  may  be  considered 
modular  -  steps  do  not  necessarily  have  to  be  completed  sequentially.  In  fact,  at  some 
points  it  may  be  desirable  to  work  concurrently  on  more  than  one  step.  The  beauty  of 
OOA&D  is  that  it  is  a  methodology  that  is  certified  by  the  International  Electrical  and 
Electronics  Engineers  (IEEE)  and  the  Object  Management  Group  (OMG),  an  industry 
standards  organization.  It  is  well  recognized  throughout  the  software  development 
industry  and  will  be  around  for  years  to  come. 

In  planning,  we  first  identified  the  critical  stakeholders.  A  critical  stakeholder  is 

someone  who  owns  a  process  or  is  a  critical  component  of  a  process.  They  could  also  be 
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viewed  as  individuals,  groups,  or  organizations  that  eould  make  or  break  the  project  if 
their  needs  are  not  met.  A  list  of  our  initial  critical  stakeholders  follows  with  supporting 
statements  attached. 

a.  Critical  Stakeholders 

1 .  Assistant  Maintenance  Officer 

The  squadron  AMO  is  responsible  for  manpower  management  within  an 

aviation  squadron. 

2.  CSFWP  Maintenance  Officer 

The  Wing  MO  receives  summary  reports  of  each  squadron’s  manning 

levels  regarding  training,  qualification,  and  quantities. 

3.  Enlisted  Personnel 

The  enlisted  personnel  whose  careers  are  managed  under  this  system 

depend  on  having  correct,  and  timely  information  entered. 

As  further  analysis  concluded,  not  every  entity  is  actually  a  critical  stakeholder  in 
every  case.  At  one  time  or  another  however,  these  proved  to  be  the  critical  stakeholders. 

b.  System  Boundary 

Identification  of  the  system  boundary  was  then  stated.  The  System 
Boundary  is  established  so  that  the  development  team  is  constrained  in  what  they  will 
address  for  system  requirements.  For  this  thesis,  we  have  determined  that  the  system 
boundary  will  be  the  application  software  developed  to  perform  requirements  of  our 
customer  as  stated  in  the  System  Functions  in  Table  1  and  use  cases  below. 

Our  system  boundary  constraint  is  the  software  system  itself.  Within  this 
boundary  lies  the  process  of  generating  one  new  T-Rating  report;  the  EDVR  is  updated 
once,  AMD  verified  once,  NEC  Award  Date  verified  once  and  a  T-Rating  report  is 
generated  and  output  once.  In  the  use  of  this  application,  one  AMO  will  be  using  only 
one  session  of  our  application  at  any  given  time.  It  is  a  stand-alone  application  at  the  user 
end.  No  network  or  connection  of  any  kind  is  assumed  to  exist  between  more  than  just 
one  AMO. 
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c.  System  Functions 

Lastly,  system  functions  were  determined  by  reviewing  established 
requirements  as  listed  in  chapter  two  of  this  thesis  and  from  survey  responses.  A 
complete  list  of  systems  functions  (what  the  system  must  do/perform)  is  displayed  in 
Table  1.  Also  listed  are  attributes,  details  and  constraints,  and  categories. 


Function 

Category 

Attribute 

Details  & 
Constraints 

Category 

Rl.l 

Import  EDVR 

Access  file  to 
Relational  db 

Evident 

Interface 

Metaphor 

Eorms  window 
should  be  easy  to 
interface  to  import 
and  initiate  system 
procedure. 
Notification  when 
complete. 

Must 

R1.2 

Import  AMD  if 
document  has  been 
changed  in  any  way. 

Evident 

Interface 

Metaphor 

Notification  when 
complete  and 

version. 

Must 

R1.3 

Compare  individuals 
listed  in  EDVR  to 
billets  listed  in  AMD 
to  “fill”  the  slots. 

Hidden 

Accuracy, 

Interface 

Metaphor 

None,  but  notify 
when  complete. 

Must 

R1.4 

Capture  NEC  field 
data  for  individuals 
from  EDVR. 

Hidden 

Accuracy, 

Interface 

Metaphor 

None,  but  notify 
when  complete. 

Must 

R1.5 

Capture  Rate/Grade 
field  data  from 

EDVR. 

Hidden 

Accuracy 

None,  but  notify 
when  complete. 

Must 

R1.6 

Capture  COB 
quantity  from 

EDVR. 

Hidden 

Accuracy 

None,  but  notify 
when  complete. 

Must 

R1.7 

Capture  experience 
time  data. 

Evident 

Interface 

Metaphor 

Eault 

tolerance 

Provide  window  for 
AMO  to  enter 
verification  criteria. 

Must  allow 
verification  saves  if 
there  is  a  break  in 
the  processing. 

Must 

R1.8 

Capture  BNEC. 

Hidden 

Accuracy 

None,  but  notify 
when  complete. 

Must 
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R1.9 

Capture  data  for 
input  from  to  Wing 
MO  (see  example). 

Evident 

Aeeuraey 

Eault 

toleranee 

Notify  upon 
eompletion. 

Must 

R2.1 

Adjust  inventory¬ 
manning  levels  as 
neeessary. 

Hidden 

Interfaee 

Metaphor 

Use  data  for  M- 
Rating  report. 

Want 

R2.2 

Log,  monthly,  status 
of  manning  levels 
and  training  levels. 

Evident 

Interfaee 

Metaphor 

Compile  historieal 
reeords  by  month  of 
eompleted 
proeessing. 

Want 

R2.3 

Log  exported  report 
to  Wing  MO. 

Evident 

Interfaee 

Metaphor 

Aeeuraey 

Create  a  log  of 
when  reports 
generation 
eompleted  and 
when  forwarded. 

Want 

R2.4 

DB  must  be  seeure 
due  to  readiness 
level/sensitivity 
nature  of  data. 

Hidden 

Aeeuraey 

Data  is  sensitive  in 
nature  and  should 
be  made 
appropriately 
seeure. 

Must 

R2.5 

Provide  a  persistent 
storage  meehanism. 

Hidden 

Eault 

toleranee 

Baek-ups  should  be 
prompted  to  be 
made  on  additional 
media. 

Must 

R2.6 

Capture  T-Rating  of 
all  rates  broken  out 
per  Wing  MO’s 
eategorization. 

Evident 

Aeeuraey 

Upon  eompletion  of 
ealeulations, 
notifieation  should 

oeeur. 

Must 

R3.1 

Provide  output  report 
to  Wing  MO  (export 
of  data) 

Evident 

Interfaee 

metaphor 

Options  TBD  still. 
Could  be  e-mail, 
hard  eopy  or  direet 
input  to  eentral 
database. 

Want 

R3.2 

Generate  report  of 
eombined  data  for 
entire  Wing  (all 
squadrons). 

Evident 

Interfaee 

metaphor 

Aeeuraey 

Pertains  to  the 

Wing  MO’s  master 
database  for  all 
squadrons. 

Must 

R3.3 

Generate  spreadsheet 
in  eolor  eodes  to 
indieate  levels  of 
qualifieation. 

Evident 

Interfaee 

metaphor 

Per  Wing  MO,  a 
stoplight  style  ehart 
is  desirable. 

Want 
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R3.4 

Search  criteria 
should  be  by  l)Rate, 

2) Pay  grade, 

3) Month  (i.e.  current 
month,  POB 1 , 
POB2,...) 

Evident 

Interface 

metaphor 

Allow  options  to 
sort  report  once 
generated. 

Want 

R3.5 

Eink  Access  from 
the  client  to  the 

Wing  MO’s  db  to  be 
able  to  directly  input 
data. 

Evident 

Interface 

metaphor 

Eault 

tolerance 

Eurther  completion 
may  include  this 
capability. 

Encryption  and 
receipt  verification 
should  be 
considered. 

Want 

Table  1.  System  Functions 


d.  High  Level  Use  Cases 

One  of  the  best  methods  used  to  gain  a  better  understanding  of 
stakeholders’  needs  and  system  requirements  is  through  the  utilization  of  use  cases.  Use 
cases  are  descriptions  of  processes  that  will  occur  within  the  system.  There  are  two 
general  types  of  use  cases:  High  Level  and  Expanded.  Initially,  use  cases  are  completed 
at  a  high  level  and  are  used  to  describe  processes  briefly  and  generally.  Expanded  use 
cases  are  used  later  in  requirements  analysis  for  further  decomposition.  The  list  of  use 
cases  considered  follows: 

1 .  Wing  MO  imports  subordinate  squadron  data  to  populate  the  database. 

2.  Wing  MO  reviews  report  generated  of  old  data  and  new  data  for 
exceptions,  changes,  and  correctness. 

3.  AMO  populates  T-Rating  calculations  with  appropriate  data  from  the 
AMD. 

4.  AMO  populates  T-Rating  calculation  with  appropriate  data  from 
NITRAS,  more  specifically,  NEC  award  dates. 

5.  Wing  MO  populates/updates  working  Wing  T-Rating  database  with 
new  data  from  squadrons. 

6.  Wing  MO  has  report  generated  from  updated  database  to  exhibit  new 
T-Rating  levels  of  all  squadrons. 

7.  Squadron  AMO  downloads/imports  current  EDVR  from  EPMAC. 

8.  AMO  populates  T-Rating  database  with  appropriate  new  data  from 
EDVR. 
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9.  AMO  generates  new  T-Ratings  to  provide  to  Wing  MO. 

10.  AMO  builds  a  new  report  to  provide  to  Wing  MO  off  new  EDVR  data. 


Ultimately,  we  narrowed  the  high-level  use  cases  down  to  just  three  in 
order  to  focus  more  on  the  essence  of  our  system  functions.  The  three  high-level  use 
cases  decided  upon  were  1)  Import  EDVR  (corresponding  to  item  #7),  2)  T-Rating 
Update  (corresponding  to  item  #9),  and  3)  Wing  MO  T-Rating  Update  (corresponding  to 
item  #5)  due  to  their  importance  and  influence  in  affecting  the  overall  system; 


Use  Case:  Import  EDVR 

Actor:  AMO  (initiator),  EPMAC,  or  Personnel  Division 


Type;  primary 

Description:  An  AMO  imports/updates  the  current  EDVR.  He  opens  the 
Access  database  and  saves  it  as  his  new  database  filename.  The  old  file  (last  month’s)  is 
archived  and  the  current  file  data  is  now  written  into  the  core  tables,  queries  and  reports. 


Use  Case;  T-Rating  Update 

Actor:  AMO 


Type;  primary 

Description;  The  AMO,  once  a  new  EDVR  is  received,  will  then  update 
the  Wing  MO  on  the  squadron’s  T-Rating.  The  T-Rating  should  take  existing  data  from 
current  databases  (i.e.  EDVR,  AMD,  NTMPS,  TFMMS,  and  NITRAS)  and  combine 
them  to  build  the  report.  Once  the  updated  T-Rating  is  calculated,  it  will  then  be  sent  to 
the  Wing  MO  so  he  can  update  the  T-Rating  Wing  wide. 


Use  Case: 

Actor: 

Type; 


Wing  MO  T-Rating  Update 
Wing  MO,  AMO 
secondary 


Description;  The  Wing  MO  receives  an  updated  T-Rating  from  each 
squadron  AMO.  Highlighted  exceptions/changes  are  reviewed.  Updated  T-Rating  report 
is  generated  from  the  updated  database  to  display  new  T-Rating  levels  of  entire  Wing. 
This  report  should  be  viewable  under  a  variety  of  sorting  options. 


28 


e. 


Use  Case  Diagram 


Use  case  diagrams  are  used  to  illustrate  entities  related  in  a  process. 
Actors,  use  cases,  system  boundaries,  and  relations  are  described  in  these  diagrams.  An 
illustrated  description  of  what  users  are  involved  with  the  system  is  given  with  use  case 
diagrams.  From  these  diagrams,  it  is  easy  to  see  the  relations  between  users  and  the 
system  and  how  they  interact.  It  is  also  a  quick  way  to  depict  the  system  boundary, 
which  is  shown  as  the  box  surrounding  the  use  cases.  In  our  application,  the  critical 
stakeholders  are  also  the  users  in  our  T-Rating  Update  model.  Figure  3  shows  how  these 
users  are  connected  through  the  system  boundary  and  which  use  cases  are  pertinent  to 
each  user. 


f.  Expanded  Use  Cases 

In  the  process  of  refining  requirements,  a  subsequent  step  to  developing 
high-level  use  cases  is  the  creation  of  expanded  use  cases.  Here,  a  more  detailed 
examination  of  what  is  to  occur  in  the  process  is  described.  Expanded  use  cases  differ 
from  high  level  ones  in  that  their  documentation  includes  a  “Typical  Course  of  Events” 
section  where  the  process  is  more  specifically  described  step-by-step.  Eisted  below  is  the 
expanded  use  case  for  the  Import  EDVR  use  case. 
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Section: 


Main 


Use  Case:  Import  EDVR 

Actors:  AMO  (initiator),  EPMAC,  or  Personnel  Division 

Purpose:  Import  the  most  current  version  of  the  EDVR  to  the 

T-Rating  database. 

Overview:  An  AMO  decides  to  update/import  the  current 

EDVR.  He  opens  the  Access  database  file  and 
archives  the  existing  database.  Then  he  opens  the 
update  file  and  saves  it  as  his  new  database 
filename.  The  current  file  data  is  now  written  into 
the  core  tables,  queries,  etc... 

Type:  primary  and  essential 

Cross  References:  Eunctions: 


Typical  Course  of  Events 

Actor  Action  System  Response 

1.  This  use  case  begins  when  the  new 
EDVR  is  sent  to  the  AMO  from  either 
EPMAC  or  Personnel  Division. 

2.  The  AMO  opens  the  new  database  file. 

•  AMO  places  new  EDVR  in 
the  appropriate  folder  for  import. 

•  AMO  imports  new  EDVR 
into  PC-EDVR. 

•  AMO  opens  T-Rating 
application. 

3.  Determines  if  EDVR  file  date  is  newer 
than  the  existing  database  file  date. 

4.  If  file  is  more  current,  prompt  to 
“update  now?” 

a.  If  “yes”,  see  section  “Update  Eile”. 

b.  If  “no”,  see  section  “No  Update  Now”. 

c.  If  “cancel”,  see  section  “Cancel”. 
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Section:  Update  File 

Actor  Action 

System  Response 

1 .  The  user  selects  “yes”. 

2.  Notify  user  that  first,  the  old  file  will  be 
archived  to  archive  folders,  then  execute 
archive  process. 

3.  Notify  user  that  new  file  will  be 
imported  and  will  overwrite  and  save  as 
current  file,  then  execute  import  process. 

4.  Notify  user  that  Refresh  must  be 
selected  in  order  to  update  queries,  reports, 
etc . . . 

5.  Notify  user  when  complete. 

Section:  No  Update  Now 

Actor  Action 

System  Response 

1 .  The  user  selects  “No”. 

2.  Notify  user  “Update  not  initiated”  and 
display  message  recommending  the  file  be 
updated  as  soon  as  possible.  Remind  user 
to  update  in  3  days. 

3.  Close. 

g.  Ranked  Use  Cases 

The  use  eases  then  need  to  be  ranked  in  order  to  determine  whieh  should 
be  deeomposed  first.  Those  use  eases  that  more  direetly  affect  the  core  architecture  of 
the  process  should  be  addressed  first.  The  ranking  scheme  may  be  complex  and 
algorithmic  or  it  may  use  a  simple  fuzzy  logic  classification  such  as  high-medium-low. 
Since  we  are  dealing  with  primarily  three  use  cases  here,  a  simple  fuzzy  classification 
will  suffice  resulting  in  the  priorities  listed  in  Table  2. 
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Rank 

Use  Case 

Justification 

High 

T-Rating  Update 

This  is  the  pivotal  proeess  of 
this  applieation. 

Medium 

Import  EDVR 

Important  proeess;  results 
fed  into  over-arehing  goal. 

Low 

Wing  MO  T-Rating  Update 

Primarily  an  output  of  the 
previous  two  use  eases. 

Low 

Start  Up* 

Definition  is  dependent  on 
other  use  eases. 

Low 

Shut  Down 

Minimal  effeet  on 
arehiteeture. 

Table  2.  Ranked  Use  Cases 


h.  T-Rating  Update  Expanded  Use  Case 

In  our  development  proeess,  we  have  performed  an  iterative  development 
eyele  around  the  deeomposition  of  our  three  use  eases.  The  first  eyele  will  undoubtedly 
be  eourse;  however,  after  iterations  where  improvements  are  implemented,  refined 
system  applieation  proeedures  will  eventually  be  aehieved.  As  listed  in  Table  2,  it  ean  be 
seen  that  use  ease  priority  one  is  the  T-Rating  Update  use  ease.  With  this,  an  expanded 
T-Rating  Update  -  version  one  use  ease  was  ereated. 

T-Rating  Update  -  Version  1 

Simplifieations,  goals,  and  assumptions 

•  Implement  EDVR  fields  only. 

•  No  oaleulations. 

•  Foeus  on  one  UIC  for  this  ease. 

•  Auto-import  from  existing  file  into  this. 

•  AMO  does  not  have  to  log  in — no  aeeess  eontrol. 

•  There  is  no  reeord  overwriting  or  arehiving  requirements. 

•  Date  of  file/report  and  UIC  updated  for  all  outputs. 

•  AMO  name  and  e-mail/phone  listed  on  outputs. 

•  Completed  T-Rating  Updates  are  saved  as  eurrent  database  and  previous 
month’s  data  is  arehived  to  an  arehive  file. 

32 


Use  Case: 


T-Rating  Update  -  version  1 


Aetors: 


AMO  (initiator),  EPMAC  or  Personnel 


Purpose: 

Overview: 


Type: 


Import  data  from  EDVR  for  T-Rating  Update 

An  AMO  deeides  to  update  T-Ratings.  The  AMO 
reeords/inputs  the  appropriate  fields/data  to  the  new 
T-Rating  database.  On  completion,  a  report  is 
generated,  the  ratings  are  calculated,  and  output  is 
generated  to  the  Wing  MO. 

primary  and  essential. 


Cross  Reference:  Eunctions:  Rl.l,  R1.4,  R1.6,  R1.9,  R3.3 


Typical  Course  of  Events 

System  Response 

I .  This  use  case  begins  when  an  AMO  sits 
down  at  the  PC  to  update  the  T-Rating 
report. 

2.  The  AMO  opens  the  T-Rating 
application. 

3.  Query  user  to  see  if  they  would  like  to 
update  the  T-Rating  report  now. 

4.  AMO  selects  “yes”  to  update. 

5.  System  updates  database  from  new  files. 

Old  file  is  archived  as  a  “filename  old” 
file. 

6.  Notifies  user  that  process  is  complete 
and  that  archive  file  now  saved  as 
“filename  old”  in  archive  folder. 

7.  Eogs  completed  actions. 

8.  AMO  logs  out  and  T-Rating  database 
has  now  been  updated  with  new  EDVR 
data. 

L  Conceptual  Model  and  Decomposition 

In  order  to  facilitate  the  identification  of  concepts  within  this  thesis,  the 

utilization  of  a  Concept  Category  Eist  is  presented.  The  goal  of  creating  a  conceptual 

model  is  to  identify  meaningful  concepts  in  the  domain  of  our  process.  The  Concept 

Category  Eist  is  used  as  a  brainstorming  tool.  Quite  often,  concepts  are  missed  in  the 

early  identification  phase,  and  then  later  discovered  during  the  design  phase.  To  prevent 

this  from  occurring  as  much  as  possible,  a  list  of  more,  rather  than  fewer,  concepts  is 
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used.  From  the  Coneept  Category  List  in  Table  3,  it  ean  be  seen  that  there  are  numerous 
eoneepts  to  eonsider. 


Concept  of  Category 

Examples 

physieal  or  tangible  objeets 

Computer 

Report 

speeifieation,  designs  or  deseriptions  of 

T-Rating  Report  Speeifieations 

things 

T-Rating  Report  Deseriptions 

plaees 

Squadron 

Wing  MO’s  Offiee 

transaetions 

Import,  Arehive  (store),  Download, 
Caleulate/Compute,  Write,  Output,  Display, 
Notify 

transaetion  line  items  (i.e.  SalesLineltems) 

EDVRFileltem 

AMDFileltem 

NECAwardDateltem 

roles  of  people 

AMO  (user) 

Wing  MO 

eontainers  of  other  things 

Database  (eontains  files) 

Memory  (eontains  files/report) 

Report  (eontains  file  data) 

things  in  a  eontainer 

Reeord  data 

Eiles,  database 

Reports 

other  eomputer  or  eleetro-meohanieal 

EPMAC,  NITRAS,  AMD  (NTMPS), 

systems  external  to  our  system 

TEMMS,  PC-EDVR 

abstraet  noun  eoneepts 

Knowledge 

Insight 

Eoresight 

Projeetion 

Manpower  Management 
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organizations 

EPMAC  (New  Orleans),  NTMPS 
(Pensacola),  Squadron,  Air  Wing, 

Personnel  Division,  Maintenance 

Department 

events 

EDVR  receipt,  EDVR  update,  T-Rating 
Calculation,  AMD  date  verification,  NEC 
Date  Verification,  Eile  Archival, 

Notification,  Report  Generation,  Output 
Eorwarding 

processes  (often  not  represented  as  a 
concept,  but  may  be) 

EDVR  receipt,  EDVR  update,  T-Rating 
Calculation,  AMD  date  verification,  NEC 
Date  Verification,  Eile  Archival, 

Notification,  Report  Generation,  Output 
Eorwarding 

rules  and  policies 

T-Rate 

policy: 

T-l  =  NEC  +  Cruise  Experience 

T-2  =  NEC  +  Work  Up  Experience 

T-3  =  NEC  Awarded 

catalogs 

NEC  catalog 

Work  center  catalog 

Area  catalog 

records  of  finance,  work,  contracts,  legal 
matters 

N/A 

manuals,  books 

OPNAVINST  1000.16H,  EDVR  Users’ 
Manual,  CSEC,  NEC  manual,  NAMP 
OPNAVINST  4790.2H 

Tables.  Concept  Category  List 


2,  Analyze  Phase 

A  major  transition  now  occurs  -  the  build  phase  appears  on  the  horizon.  In  the 
build  phase,  iterative  development  cycles  occur  as  well.  Then  an  analyze  phase  or 
analysis  phase  is  started,  within  which  the  problems  of  the  current  cycle  are  closely 
investigated. 


a.  Initial  Concept  Model 
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The  most  critical  model  to  develop  during  the  analysis  phase  is  the 
Conceptual  Model.  The  conceptual  model  is  important  because  it  is  from  here  that 
objects  begin  to  take  form  for  use  in  the  design  phase.  The  conceptual  model  basically 
illustrates  the  meaningful  concepts  taken  from  the  Concept  Category  List  and  displays 
them  in  no  particular  fashion  -  the  Concept  Category  List  was  merely  used  as  a  tool  in 
generating  concepts.  Table  4  below  is  a  list  of  the  concepts  considered  pertinent  to  our 
application. 

While  all  concepts  listed  below  are  not  critical  system  process  concepts, 
for  documentary  purposes,  we  have  listed  them.  Ideally,  the  identification  of  concept 
objects  is  derived  from  expanded  use  cases.  In  this  case;  however,  it  was  our  desire  to 
review  all  potential  concepts  in  this  process  for  reasons  discussed  in  paragraph  Li  above. 

b.  Associations 

Associations  describe  how  concepts  are  related  to  each  other.  It  is 
important  to  distinguish  relationships  that  need  to  be  established  for  an  indefinite  period 
of  time  regardless  of  duration.  We  have  created  a  Common  Associations  List  as  a  tool  to 
aid  in  identification  and  definition  of  associations  here.  This  list  may  be  viewed  in  its 
entirety  in  Appendix  B.  Next,  from  this  list,  we  then  illustrated  these  associations,  in 
relation  to  the  concepts  in  the  Conceptual  Models.  The  individual  diagrams  resulting 
from  this  process  may  be  viewed  in  Appendix  C.  In  an  effort  to  condense  these  separate 
conceptual  models  down  to  one  that  was  concise  and  easier  to  convey  the  domain  with 
which  we  are  dealing,  the  Automated  T-Rating  Conceptual  Model  with  associations  was 
created  as  shown  in  Figure  4. 
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,  Application  Software 
\  Development 


Analysis  Usp^^ 
Case  Mcxie 


Conceptual  Model 


SystertT  Behavior 
Mode  " 


Analysis  State 
Model 


Computer 


T-Rating  Report 


T-Rating 

Specification 

T-Rating 

Description 

Squadron 

Wing  MO's  Office 

EDVR  File  Item 

AMD  File  Item 

NEC  Award  Date 
Item 

AMO  (user) 

Wing  MO 

Manpower 

Database 

Memory 

NTMPS 

EPMAC 

NITRAS 

AMD  (NTMPS) 

TFMMS 

PC-EDVR 

Area  Description 

Air  Wing 


Personnel 

Division 


Maintenance 

Department 


EDVR  Receipt 


EDVR  Update 


T-Rating 

Calculations 


AMD  Verfication 


NEC  Date 
Verification 


File  Archival 


Notification 


Report 

Output 

Generation 

Forwarding 

T-Rate  Policy 


NEC  Catalog 


Work  Center 
Catalog 


Area  Catalog 

EDVR 

AMD 

NITRAS 

AMO'S  Database 

Wing  MO's 

OPNAV 

EDVR  Users' 

CSEC 

NEC  Manual 

Database 

1000.16H 

Manual 

(OPNAV  ) 

NAMP (OPNAV 
4790.2H) 

Hangar 

File 

NEC  Description 

Workcenter 

Description 


Table  4.  Conceptual  Objects  (from  Larman,  p.  103) 
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Automatic  T-Rating  Conceptual  Model 


4.  Concept  Model  and  Assoeiations 


As  with  the  creation  of  concepts,  when  defining  associations,  concern 
should  not  be  given  to  whether  the  association  will  be  used  during  design  and 
construction.  The  goal  is  to  establish  associations  between  concepts  that  have  been 
created. 

In  generating  associations  for  this  application,  the  following  guidelines 

were  used: 

•  Focus  on  those  associations  for  which  knowledge  of  the  relationship  needs 
to  be  preserved  for  some  duration  (“need-to-know”  associations). 

•  It  is  more  important  to  identify  concepts  than  to  identify  associations. 

•  Too  many  associations  tend  to  confuse  a  conceptual  model  rather  than 
illuminate  it.  Their  discovery  can  be  time-consuming,  with  marginal 
benefit. 

•  Avoid  showing  redundant  or  derivable  (common  sense)  associations. 

c.  Discussion  of  Conceptual  Model  Attributes 

At  this  point,  it  is  beneficial  to  identify  the  attributes  of  the  concepts  that 
are  needed  to  satisfy  information  requirements  of  current  use  cases  under  development. 
An  attribute  is  a  logical  data  value  of  an  object.  Attributes  are  shown  in  the  lower  section 
of  the  concept  box  of  Figure  5.  A  complete  list  of  statements  supporting  the  reason 
behind  each  attribute  may  be  found  in  Appendix  D.  It  is  desirable  to  have  such  a  list 
drawn  up  in  order  to  see,  very  quickly,  where  the  relation  occurs  and  why  it  is  important 
that  each  attribute  be  listed  for  the  related  concept. 

Taking  these  concepts,  associations,  and  attributes  we  arrive  at  the  final  T- 
Rating  Conceptual  Model  as  illustrated  below  in  Figure  6.  It  should  be  noted  here,  that 
there  is  no  such  thing  as  a  “right”  or  “wrong”  concept  model.  Conceptual  models  should 
be  used  as  tools  to  understand  and  establish  the  requirements  of  the  system.  Better 
models  make  it  clearer  for  people  to  see  overall,  how  the  system  will  be  designed,  based 
on  known  information. 

With  this,  we  can  see  what  the  final  T-Rating  Conceptual  Model,  with 
associations  and  attributes,  will  look  like  and  from  which  we  can  then  analyze  and  gain 

further  understanding  of  for  the  design  phase.  Figure  6  depicts  this  final  diagram. 
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T-Rating  Concept  Attributes 


EDVR 


+date  :  Date 
+uic  :  Integer 


EDVRFileltem 


+uic  :  Integer 
+rate  :  String 
+cob  :  Integer 
+eda/l  :  Date 
+  nec1  :  Integer 
+  nec2  :  Integer 
+a/c  t/m/s  :  String 
+area  :  String 


AMO 


+rank  :  String 
+  name  :  String 
+command  :  String 
+uic  :  Integer 
+  phone  :  Integer 
+e-mail  :  String 


EDVRUpdate 

+date 

:  Date 

+time 

:  fixed(idl) 

+uic  : 

Integer 

NTMPS 


PC-EDVR 


MSAccess 


AM  DFileltem 


+uic  :  Integer 
+  bsc  :  Integer 
+  bnec  :  Integer 
+  brate  :  String 


EPMACCode49  (orNTMPS) 


NECDateVerification 


WingMO 


+rank  :  String 
+  name  :  String 


Report 


+date  :  Date 
+time  :  String 


+command  :  String  +uic  :  Integer 


+uic  :  Integer 
+  phone  :  Integer 
+e-mail  :  String 


ManpowerDatabase 


+area  :  String 
+experience  :  String 


NECDateVerification  Item 


+date  :  Date 
+time  :  String 
+  name  :  String 
+rate  :  String 
+uic  :  Integer 
+ssn  :  Integer 
+  nec1  :  Integer 
+  nec2  :  Integer 
+date  awarded  :  Date 
+experience  :  String 


+command  :  String 
+submitted  by  :  String 
+edvr  date  :  Date 
+amd  date  :  Date 


EDVR 


+date  :  Date 
+uic  :  Integer 


AMD 


+date  :  Date 
+uic  :  Integer 


Notification 

+date  :  Date 
+time  :  fixed(idl) 
+title  :  String 


F igure  5 .  Concept  Attributes 
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Figure  6.  Conceptual  Model  with  Attributes 
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d.  System  Sequence  Diagrams 

The  use  of  System  Sequence  Diagrams  is  important  in  the  analysis  phase 
because  they  depict,  in  the  UML  notation,  the  important  functions  of  the  system 
processes  and  how  they  are  related  to  the  users,  or  Actors  as  they  are  termed  in  the  UML 
notation.  Other  important  factors  that  are  identified  in  the  diagram  are  things  such  as  the 
use  case,  event  orders,  and  intersystem  events.  Emphasis  should  be  given  to  events  that 
reach  beyond  the  system  boundary,  depicted  as  an  outlined  box  that  contains  use  cases. 
Things  outside  this  boundary  are  considered  external,  such  as  the  actors  in  our  case.  One 
additional  issue  that  is  considered  here  is  that  of  system  behavior.  This  behavior  is  what 
is  important  and  describes  more  of  what  a  system  does  rather  than  how  it  is  done.  Figure 

7  illustrates  the  use  case  from  the  perspective  of  the  AMO  and  the  system  events.  Figure 

8  illustrates  the  use  case  from  the  perspective  of  the  Wing  Maintenance  Officer. 
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Automated  T-Rating  System 
Sequence  Diagram 

o 


AMO 


For  the  EDVR  update,  the  AMO 
records  the  UlC,  Rate,  COB,  EDA/L, 
NEC1,  NEC2,  A/C  T/M/S  and  Area. 


addEDVRO  i 

- 


For  the  AMD,  the  AMO  records  the 
UlC,  BSC,  BNEC,  BRate,  AMD  Date. 


addAMDO  [ 

- W 


From  the  NEC  Date  Verification,  the 
AMO  records  the  date  NEC  awarded 
and  experience  amount. 


addNECDateVerificationO  i 

- ►! 


On  completion  of  record  entries,  the 
AMO  indicates  to  the  Application  that 
the  input  is  complete. 


endCalculationsO  [ 

- 


Figure  7.  AMO  System  Sequence  Diagram 
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Automated  T-Rating  System 
Sequence  Diagram 


o 


WingMO 


:Svstem 


Upon  completion  of  the  T-Rating 
Calculation,  a  T-Rating  Report  is 
output  to  the  Wing  MO. 


makeOutputO 


Figure  8.  Wing  MO  System  Sequenee  Diagram 
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From  the  system  sequenee  diagrams,  it  ean  be  seen  that  the  system  will 
have  four  input  messages  and  one  output  message,  whieh  make  up  the  five  system 
operations.  These  operations  are  explained  as  a  system  response  to  an  event  initiated  by 
an  external  input  sueh  as  an  aetor.  Figure  9  depiets  in  the  UML  notation  the  five  system 
operations  that  will  need  to  be  performed. 


:  System 

addEDVRO 

addAMDO 

addNECDateVerificationQ 
endC  alculationsO 
makeOutputO 

Eigure  9.  System  Operations 
e.  Contracts 

The  last  aspeet  of  the  analyze  phase  that  needs  to  be  eonsidered  is  that  of 
eontraet  ereation.  Contraets  are  ereated  to  detail  what  more  speeifieally  should  happen  in 
the  system  operations.  They  are  more  ideally  the  proeess  of  what  happens  in  the  events 
that  will  take  place  in  terms  of  state  changes  from  before  the  event  operation  to  after  the 
event.  In  essence,  a  contract  is  used  to  capture  the  behavior  of  the  system  in  more  detail 
so  that  the  developer  can  start  to  move  toward  the  next  phase  where  building  begins. 

A  description  of  each  section  of  a  contract  is  shown  in  the  following 


schema  of  Table  5.  Not  all  sections  are  necessary,  although  the  Responsibilities  and 
Post-Conditions  sections  are  recommended. 


Name: 

Name  of  operations  and  parameters. 

Responsibilities: 

An  informal  deseription  of  the  responsibilities  this  operation  must  fulfill. 

Type: 

Name  of  type  (eoneept,  software  elass,  interfaee) 

Cross  References: 

System  funetion  referenee  numbers,  use  eases,  ete. 

Notes: 

Design  notes,  algorithm,  and  so  on. 

Exceptions: 

Exeeptional  eases. 

Ontpnt: 

Non-UI  outputs,  sueh  as  messages  or  reeords  that  are  sent  outside  of  the  system. 

Pre-Conditions: 

Assumptions  about  the  state  of  the  system  before  exeeution  of  the  operations. 

Post-Conditions: 

The  state  of  the  system  after  eompletion  of  the  operation. 

Tables.  Contract  Schema 
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Contracts  pertinent  to  the  Automated  T-Rating  system  operations  are  the  adding 
of  the  EDVR  to  the  system  database,  adding  the  AMD  to  the  system  database,  adding  the 
NEC  Date  Verifieation  to  the  database,  ending  the  Caleulations  when  all  EDVR,  AMD 
and  NEC  Date  data  is  present,  and  lastly,  making  output  as  in  the  form  of  reports. 


Name: 

Responsibilities: 

Type: 

Cross  References: 
Notes: 

Exceptions: 

Output: 

Pre-conditions: 


addEDVR 

Enter  (record)  the  newly  received  EDVR  file  for  use  in  the  T- 
Rating  Caleulation. 

System 

System  Eunetions:  Rl.l,  R1.3,  R1.4,  R1.5,  R1.6 


EDVR  file  is  saved  to  a  specifie  loeation  in  order  for  system  to 
address  it  for  import. 


Post-conditions: 

•  If  a  new  T-Rating  ealeulation,  a  T-RatingCalculations  was  ereated. 

•  A  T-RatingCalculationLineltem  was  ereated. 

•  If  a  new  T-Rating  ealeulation,  the  new  T-Rating  was  assoeiated  with  the 
Manpower  Database  (assoeiation  formed). 

•  The  EDVRLineltem  was  assoeiated  with  the  T-Rating  Calculations. 

•  If  EDVR  import  was  eompleted,  a  Notification  message  was  ereated. 


Name: 

Responsibilities: 

Type: 

Cross  References: 
Notes: 

Exceptions: 

Output: 

Pre-conditions: 


addAMD 

Enter  the  AMD  data  for  use  in  the  T-Rating  Caleulation. 
System 

System  Eunetions:  R1.2,  R1.3,  R1.9 


AMD  is  saved  to  a  speeifie  loeation  in  order  for  system  to  address 
it  for  import. 
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Post-conditions: 


•  If  a  new  T-Rating  calculation,  a  T-RatingCalculations  was  created. 

•  If  a  new  T-Rating  calculation,  a  T-RatingCalculationLineltem  was  created. 

•  The  T-Rating  was  associated  with  the  Manpower  Database. 

•  An  AMDLineltem  was  created. 

•  The  AMDLineltem  was  associated  with  the  T-RatingCalculations . 

•  If  AMD  import  was  completed,  a  Notification  message  was  completed. 


Name: 

Responsibilities: 

Type: 

Cross  References: 
Notes: 


Exceptions: 

Output: 

Pre-conditions: 


addNECDateVerification 

Enter  the  NEC  Award  Date  for  use  in  the  T-Rating  Calculation. 
System 

System  Eunctions:  R1.8 

This  is  a  process  that  may  require  a  number  of  repetitive  cycles  as 
each  individual’s  NEC  award  date  will  need  to  be  verified; 
something  that  may  not  be  performed  in  one  step. 


Members  already  onboard  have  been  verified.  Only  new  gains  will 
require  verification. 


Post-conditions: 

•  If  a  new  T-Rating  calculation,  a  T-RatingCalculation  was  created. 

•  If  a  new  T-Rating  calculation,  A  T-RatingCalculationLineltem  was 
created. 

•  The  T-Rating  was  associated  with  the  Manpower  Database. 

•  An  NECDateVerificationLineltem  was  created. 

•  The  NECDateVerificationLineltem  was  associated  with  the  T- 
RatingCalculation. 

•  If  NECDateVerification  was  completed,  a  Notification  message  was 
created. 
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Name: 

endCalculations 

Responsibilities: 

Record  that  it  is  the  end  of  entry  of  T-Rating  items,  and  display  T- 
Rating  report  totals. 

Type: 

System 

Cross  References: 

System  Functions:  R2.6. 

Notes: 

This  is  notification  to  the  system  that  all  entries  for  the  T-Rating 
Calculation  are  complete;  proeessing  may  commence  now. 

Exceptions: 

Output: 

On-Screen  visual  notification. 

Pre-conditions: 

EDVR,  AMD,  NECDateVerification  are  known  to  the  system. 

Post-conditions: 

•  T-Rating.isComplete  was  set  to  true  (attribute  modification). 

Name: 

makeOutput 

Responsibilities: 

Record  the  T-Rating  Calculation,  make  output  to  designated 
addressees. 

Type: 

System 

Cross  References: 

System  Eunctions:  R3.1,  R3.2,  R3.3,  R3.4. 

Notes: 

Exceptions: 

Output: 

database  file,  e-mail,  hard  eopy  (for  binders  that  may  be  kept). 

Pre-conditions: 

Post-conditions: 

•  Output  is  created. 
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3,  Design  Phase 

In  this  section,  we  make  the  transition  to  design  where  the  actual  concepts  of 
operation  will  be  drawn  out  more  specifically.  Again,  we  have  primarily  been  concerned 
with  the  what  that  the  system  must  do.  Here,  though  we  start  to  concentrate  on  how 
things  will  be  processed. 

In  the  design  phase,  a  logical  solution  is  presented  to  address  the  issues  identified 
during  the  previous  two  phases  of  Plan  and  Elaborate,  and  Analysis.  The  pinnacle 
element  of  these  two  phases  is  the  creation  of  collaboration  diagrams.  In  collaboration 
diagrams,  we  diagram  the  process  that  is  to  satisfy  the  requirement  so  written  for.  In  this 
section  of  the  thesis,  we  present  our  description  of  the  real  use  cases,  diagram  how  our 
system  processes  will  communicate  in  the  form  of  collaboration  diagrams,  and  lastly, 
summarize  the  critical  links  through  the  creation  of  the  Design  Class  Diagram. 
a.  Real  Use  Case  Description 

In  the  design  phase,  there  are  no  high-level  or  expanded  use  cases. 
Instead,  these  are  utilized  in  terms  of  real  use  cases.  By  real,  what  is  meant  is  that  the  use 
case’s  actual  design  will  be  described  using  concrete  input  and  output,  as  well  as 
implementation  methodologies.  In  this  instance,  we  have  taken  the  Import  EDVR  use 
case  and  described  more  specifically,  using  storyboarding,  how  the  use  case  would  be 
realized.  As  is  shown,  a  graphical  user  interface  will  be  used  to  provide  a  means  of 
communication  between  the  user  and  the  system.  At  this  point,  the  application  is  not 
fully  developed,  but  with  the  depiction  of  the  basic  GUI  windows,  it  becomes  easier  to 
see  how  the  system  may  function  as  well  as  identify  other  requirements  that  need  to  be 
addressed. 
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Typical  Course  of  Action 

Actor  Action 

System  Response 

1.  This  use  case  begins  when  a  new 
EDVR  has  been  posted  to  the  LAN  by  the 
Command  Career  Counselor  or  Pers  Div. 

2.  The  AMO  will  copy  this  file  into  the 
folder  c  :\\prometheus\edvr\import 

3.  The  AMO  will  double  click  the 
Prometheus  icon  to  open  the  application. 

4.  Prometheus  application  will  launch. 

5.  Prompt  user  to  import  new  EDVR  from 
c  :\\Prometheus\edvr\import. 

Prometheus 


m 


Would  you  like  to  import  a  new  EDVR  for 
updating? 

Yes  I  No  I 


6.  The  system  opens  the  new  EDVR  .txt 
file,  and  then  copies  the  data/fields  into 
the  Prometheus  database. 

7.  The  AMO  will  select  the  “yes”  button 
to  confirm. 

8.  Name  of  EDVR  file  should  already 
exist.  Prompt  user  to  rename  and  archive 
the  old  file 

9.  Old  file  will  be  renamed  as 

<DD  MMM  YY.  >  and  moved  into  the 
folder  c  :\\Prometheus\edvr\archives 

10.  Notify  user  that  import  process  has  been 
complete. 
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1 1 .  Prompt  user  to  view  or  print  out  new 
EDVR. 


b.  Collaboration  Diagrams 

In  the  UML,  two  kinds  of  interaction  diagrams  exist:  sequence  and 
collaboration.  Either  may  be  used  to  express  message  interaction;  however,  collaboration 
diagrams  are  preferred  because  they  are  better  suited  to  expressing  system  operations 
flow  as  well  as  describe  the  contextual  meaning  of  such  operations. 

The  collaboration  diagrams  use  the  pre-  and  post-conditions  of  the 
contracts  in  section  2.e  of  this  chapter,  and  illustrate  message  interactions.  A  description 
of  each  diagram  follows: 
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addAMD  Collaboration  Diagram 


Figure  10.  Add  AMD  Collaboration  Diagram 
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The  addAMD  collaboration  diagram  in  Figure  10  is  read  as  follows: 

1.  The  message  addAMD  is  sent  to  an  instance  of  Prometheus.  It 
corresponds  to  the  addAMD  system  operation  message. 

2.  The  Prometheus  object  sends  the  addAMD  message  to  a  T- 
RatingCalculation  instance. 

3.  The  T-RatingCalculations  object  creates  an  instance  of 
CalculationLineltem . 

4.  The  Prometheus  object  sends  the  getAMD  message  to  an  AMD  instance. 

5.  The  AMD  object  finds  the  datafields  in  the  AMD  and  creates  an  instance 
of  AMDLineltem  called  for. 

6.  The  T-RatingCalculations  object  creates  a  TRCLineltem  with  the  AMD 
data  found  in  the  instance  of  AMDLineltem. 

1.  The  TRCLineltem  just  created  is  then  added  to  and  stored  in  the  object 
CalculationLineltem . 
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addEDVR  Collaboration  Diagram 


Figure  1 1 .  Add  EDVR  Collaboration  Diagram 
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The  addEDVR  collaboration  diagram  in  Figure  1 1  is  read  as  follows: 

1.  The  message  addEDVR  is  sent  to  an  instance  of  Prometheus.  It 
corresponds  to  the  addEDVR  system  operation  message. 

2.  The  Prometheus  object  sends  the  addEDVR  message  to  a  T- 
RatingCalculation  instance. 

3.  The  T-RatingCalculation  object  creates  an  instance  of 
CalculationLineltem . 

4.  The  Prometheus  object  sends  the  getEDVR  message  to  an  EDVR 

instance. 


5.  The  EDVR  object  finds  the  data  fields  in  the  EDVR  and  creates  an 
instance  of  EDVRLineltem  called  for. 


6.  The  T-RatingCalculation  object  creates  a  TRCLineltem  with  the  EDVR 
data  found  in  the  instance  of  EDVRLineltem. 


7.  The  TRCLineltem  just  created  is  then  added  to  and  stored  in  the  object 
CalculationLineltem . 
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Figure  12.  Add  NEC  Date  Verification  Collaboration  Diagram 


The  addNECDateVerification  collaboration  diagram  in  Figure  12  is  read 

as  follows: 


1.  The  message  addNECDateVerification  is  sent  to  an  instance  of 
Prometheus.  It  corresponds  to  the  addNECDateVerification  system  operation  message. 
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2.  The  Prometheus  object  sends  the  addNECDateVerification  message  to  a 
T-RatingCalculation  instance. 

3.  The  T-RatingCalculation  object  creates  an  instance  of 

CalculationLineltem . 

4.  The  Prometheus  object  sends  the  getNECDateVer  message  to  a 
NECDateVerification  instance. 

5.  The  NECDateVerification  object  finds  the  data  in  the 

NECDateVerification  report  and  creates  an  instance  of  NECDateVerLineltem  called  for. 

6.  The  T-RatingCalculation  object  creates  a  TRCLineltem  with  the  NEC 
date  data  found  in  the  instance  of  NECDateVerLineltem. 

7.  The  TRCLineltem  just  created  is  then  added  to  and  stored  in  the  object 
CalculationLineltem . 
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endCalculation  Collaboration 

Diagram 


Figure  13.  End  Calculation  Collaboration  Diagram 

The  endCalculation  collaboration  diagram  in  Figure  13  is  read  as  follows; 

1 .  The  message  endCalculations  is  sent  to  an  instance  of  Prometheus.  It 
corresponds  to  the  endCalculations  system  operation  message. 

2.  The  Prometheus  object  sends  a  becomeComplete  message  to  a  T- 
RatingCalculation  instance. 

3.  The  becomeComplete  message  is  a  simple,  standard  message  to  end 

processing. 
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makeOutput  Collaboration  Diagram 


K 

K 

byController 

byCreator 

makeOutputO 


.1  :[newCalculation]createQ 


3:makeOutput(t-RatingReportFields)() 


:Prometheus^ 


:T-RatingCalculation 


Figure  14.  Make  Output  Collaboration  Diagram 

The  makeOutput  collaboration  diagram  in  Figure  14  is  read  as  follows: 

1.  The  message  makeOutput  is  sent  to  an  instance  of  Prometheus.  It 
corresponds  to  the  makeOutput  system  operation  message. 

2.  The  Prometheus  object  creates  a  T-RatingCalculation  object. 

3.  The  T-RatingCalculation  object  sends  the  getTRC  to  the  container 
CalculationLineltem . 

4.  The  T-RatingCalculation  object  sends  the  makeOutput  message  to  the 
report  object  T-RatingCalculation. 
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5.  The  report  objeet  sends  a  create  message  to  the  Report  objeet  in  the 
format  desired  by  the  user  (i.e.  printer  or  file). 
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startup  Collaboration  Diagram 


Figure  15.  Start-up  Collaboration  Diagram 
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The  startup  collaboration  diagram  in  Figure  15  is  read  as  follows: 

1 .  The  message  create( )  is  sent  to  an  instance  of  Prometheus. 

2.  The  object  Prometheus  sends  a  create( )  message  to  instances  of  EDVR, 
AMD,  and  NECDateVerification. 

3.  The  objects  EDVR,  AMD,  and  NECDateVerification  send  a 
load*LineItem  message  to  themselves  to  initialize  these  objects  for  system  operation. 

c.  Design  Class  Diagram 

In  furthering  this  application  from  just  an  idea  to  real  code,  we  come  to  the 
use  of  the  class  diagram.  Typical  information  contained  in  class  diagrams  is: 

•  classes,  associations,  attributes 

•  interfaces  with  their  operations  and  constraints 

•  methods 

•  attribute  type  information 

•  navigability 

•  dependencies 

Whereas  in  the  conceptual  model  where  objects  do  not  necessarily 
represent  software  definitions,  in  class  diagrams  abstractions  of  these  concepts  are 
defined  in  terms  of  software  classes  and  components.  The  diagram  in  Figure  16 
describes  the  information  listed  above  for  our  application.  One  note  regarding  class 
diagrams  however,  they  should  be  created  taking  into  consideration  the  intended 
audience.  If  a  CASE  tool  with  automatic  code  generation  is  to  be  used,  then  full  and 
exhaustive  details  are  necessary.  But  if  the  class  diagrams  are  being  created  for  software 
developers  to  read,  exhaustive  detail  may  adversely  affect  any  intended  value  added. 
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Design  Class  Diagram 


Figure  16.  Design  Class  Diagram 
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4,  Summary 

In  this  chapter,  we  have  performed  requirements  analysis  by  taking  an  Object 
Oriented  Analysis  and  Design  approach.  We  have  used  the  Unified  Modeling  Language 
to  identify,  diagrammatically,  the  objects  of  the  applieation  and  how  these  objeets 
interrelate  with  eaeh  other  in  its  domain.  The  goal  of  this  phase  of  development  has  been 
to  identify  entities,  classes  and  links  so  that  the  software  developer  may  be  able  to 
duplicate  as  close  as  possible,  the  business  process  ideas  of  the  customer  and  reproduce 
them  in  code  represented  by  the  software  application  developed  in  this  thesis.  The  next 
step  is  to  begin  writing  the  code  neeessary  to  produee  something  more  tangible  for  the 
user. 
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IV.  MICROSOFT®  .NET  FRAMEWORK,  VISUAL  BASIC.NET 
AND  ADO.NET  IMPLEMENTATION 

A,  INTRODUCTION 

The  vast  majority  of  applications  built  today  involve  data  manipulation  in  some 
way — whether  it  is  retrieval,  storage,  change,  translation,  verification,  or  transportation. 
For  an  application  to  be  scalable  and  allow  other  applications  to  interact  with  it,  the 
application  will  need  a  common  mechanism  to  pass  the  data  between  the  data  provider 
and  data  consumers.  Ideally,  the  vehicle  that  transports  the  data  should  contain  the  base 
data,  any  related  data  and  metadata,  and  be  able  to  track  changes  to  the  data  as  well.  The 
Prometheus  application  uses  the  Microsoft®  .NET  Framework  Visual  Basic.NET 
(VB.NET)  and  ADO.NET  to  accomplish  these  tasks. 

There  have  been  many  methods  of  handling  data  in  previous  versions  of  Visual 
Basic,  beginning  with  the  simple  Data  Access  Objects  (DAO)  protocol,  then  Remote- 
access  Data  Objects  (RDO),  followed  by  ActiveX  Data  Objects  (ADO),  which  has 
evolved  today  into  ADO.NET.  ADO.NET  leverages  the  power  of  Extensible  Mark-up 
Language  (XML)  to  provide  disconnected  access  to  data.  ADO.NET  was  designed  hand- 
in-hand  with  the  XML  classes  in  the  .NET  Framework — both  components  of  a  single 
architecture.  (Holzner,  p.  19) 

ADO.NET  and  the  XML  classes  in  the  .NET  Framework  converge  in  the  DataSet 
object.  The  DataSet  can  be  populated  with  data  from  an  XML  source,  whether  it  is  a  file 
or  an  XML  stream.  The  DataSet  can  be  written  as  World  Wide  Web  Consortium  (W3C) 
compliant  XML,  including  its  schema  as  XML  Schema  definition  language  (XSD) 
schema,  regardless  of  the  source  of  the  data  in  the  DataSet.  Because  the  native 
serialization  format  of  the  DataSet  is  XML,  it  is  an  excellent  medium  for  moving  data 
between  tiers  making  the  DataSet  an  optimal  choice  for  remote  data  access  and  schema 
context  to  and  from  an  XML  service. 
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B,  ADO.NET  ARCHITECTURE 

Data  processing  has  traditionally  relied  primarily  on  a  eonneetion-based,  two-tier 
model.  As  data  proeessing  inereasingly  uses  N-tier  arehiteetures,  programmers  are 
switehing  to  a  diseonneeted  approaeh  to  provide  better  sealability  for  their  appbeations. 
The  Prometheus  applieation  utilizes  the  two-tier  arehiteeture,  though  it  is  built  upon  the 
ADO.NET  prineiples  laid  out  in  this  seetion  for  future  N-tier  implementation  and 
sealability.  (MSDN  Library) 

Note  that  ADO  is  no  longer  built  into  Visual  Basic.  ADO  was  based  on 
Component  Objeet  Model  (COM)  protoeols,  and  COM  (as  well  as  DCOM)  is  no  longer 
built  into  Visual  Basie  either.  Instead,  ADO.NET  uses  XML  to  exehange  data.  Both 
COM  and  distributed  COM  (DCOM)  teehnology  has  been  replaeed  by  the  .NET 
framework.  (Holzner,  p.  19) 

The  ADO.NET  eore  eomponents  have  been  designed  to  faetor  data  aeeess  from 
data  manipulation  as  illustrated  in  Eigure  17.  There  are  two  eentral  eomponents  of 
ADO.NET  that  aoeomplish  this:  1)  the  DataSet  and  2)  the  .NET  data  provider,  whieh  is  a 
set  of  eomponents  ineluding  the  Conneetion,  Command,  DataReader,  and  DataAdapter 
objeets. 

The  other  eore  element  of  the  ADO.NET  arehiteeture  is  the  .NET  data  providers, 
whose  eomponents  are  explieitly  designed  for  data  manipulation  and  fast,  forward-only, 
read-only  aeeess  to  data.  The  Conneetion  objeet  provides  eonneetivity  to  a  data  souree. 
The  Command  objeet  enables  aeeess  to  database  eommands  to  return  data,  modify  data, 
run  stored  proeedures,  and  send  or  retrieve  parameter  information.  The  DataReader 
provides  a  high-performanee  stream  of  data  from  the  data  souree.  Einally,  the 
DataAdapter  provides  the  bridge  between  the  DataSet  objeet  and  the  data  souree.  The 
DataAdapter  uses  Command  objeets  to  exeeute  SQL  eommands  at  the  data  souree  to  both 
load  the  DataSet  with  data,  and  reeoneile  ehanges  made  to  the  data  in  the  DataSet  baek  to 
the  data  souree.  (MSDN  Library) 
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Figure  17.  ADO.NET  architecture  and  components 


C.  ADO.NET  COMPONENTS 


ADO  is  a  Component  Object  Model  interface  to  Object  Linking  and  Embedding 
(OLE)  DB  providers;  OLE  DB  expects  to  be  accessed  by  consumers  such  as  ADO. 
Figure  18  illustrates  the  OLE  DB  architecture.  Formally,  an  OLE  DB  Consumer  is  any 
piece  of  system  or  application  code  that  consumes  an  OLE  DB  interface,  including  the 
OLE  DB  components  themselves.  Figure  19  illustrates  how  ADO  interfaces  with  the 
OLE  DB  object.  (Vaughn,  p.  15) 


Data 


Figure  18.  OLE  DB  Architecture 
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Figure  19.  ADO  -  OLE  DB  Object  Interface 


A  provider  is  any  software  component  that  exposes  an  OLE  DB  interface.  OLE 
DB  providers  can  be  classified  broadly  into  two  classes:  data  providers  and  service 
components. 

A  data  provider  is  any  OLE  DB  provider  that  owns  data  and  exposes  its  data  in  a 
tabular  form  as  a  rowset,  which  is  defined  later  in  this  section.  Examples  of  data 
providers  include  relational  database  management  systems  (RDBMS),  storage  managers, 
spreadsheets,  and  service  components.  Prometheus  uses  the  Jet  4.0  provider,  which  is  the 
only  native  OLE  DB  provider  available  to  access  a  Microsoft®  Access  (DBMS) 
database.  The  Microsoft®  OLE  DB  Provider  for  Jet  provides  an  OLE  DB  interface  to 
Microsoft®  Access  databases  and  allows  Microsoft®  SQL  Server™  2000  distributed 
queries  to  query  Access  databases.  (Vaughn,  p.  15) 

A  service  component  is  any  OLE  DB  component  that  does  not  own  its  own  data, 
but  encapsulates  some  service  by  producing  and  consuming  data  through  OLE  DB 
interfaces.  A  service  component  is  both  a  consumer  and  a  provider.  Eor  example,  a 
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heterogeneous  query  processor  is  a  service  component  -  it  has  to  draw  data  from  one 
source,  restructure  it,  and  pass  it  up  the  food  chain  to  the  requesting  component,  the 
consumer.  (Vaughn,  p.  15-16) 

A  database  management  system  (DBMS)  is  a  type  of  data  source  whose  job  it  is 
to  return  information  in  one  form  or  another  as  an  OLE  DB  data  provider.  In  the 
Prometheus  implementation,  the  DBMS  is  segmented  into  functional  pieces 
(components)  -  each  handling  a  specific  job.  In  theory,  component  DBMS’s  offer  greater 
efficiency  than  traditional  DBMS’s  because  consumers  generally  require  only  a  portion 
of  the  database  management  functionality  offered,  thereby  reducing  resource  overhead. 
OLE  DB  enables  simple  tabular  data  providers  to  implement  functionality  native  to  their 
tables.  (Vaughn,  p.  16)  Microsoft®  Access  2002  was  chosen  as  a  stand-alone  DBMS  for 
its  powerful  management  and  analyzing  capabilities.  This  application  was  chosen  for 
proof  of  concept  primarily,  although  Access  provides  full  XML  support,  enabling  the 
creation  of  a  sophisticated  enterprise-wide  database  solution.  The  Prometheus  E-Pro 
Alpha.mdb  file  can  be  integrated  easily  with  the  Web  and  ported  over  to  a  Microsoft® 
SQL  Server  DBMS  with  minimal  programmatic  changes.  The  following  illustration  of 
Eigure  20  shows  major  components  of  the  ADO.NET  application. 

ADO.NET  Data  Components 


Eigure  20.  ADO.NET  Components 
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1. 


DATA  PERSISTED  AS  XML 


ADO.NET  is  a  new  data-handling  model  that  makes  it  easy  to  handle  data  on  the 
Internet  and  on  a  loeal  maehine  to  communieate  with  loeal  databases  the  way  Prometheus 
does.  At  the  heart  of  ADO.NET  is  XML;  all  data  is  represented  in  XML  format  and 
exehanged  that  way.  Prometheus  uses  XML  via  the  VB.NET  applieation  development 
environment  to  translate,  verify,  and  exchange  data. 

Data  needs  to  be  moved  from  the  data  store  to  the  DataSet  and  from  there  to 
various  components.  In  ADO.NET,  the  format  for  transferring  data  is  XML.  Similarly, 
if  data  needs  to  be  persisted,  into  a  file  for  example,  it  is  stored  as  XML.  If  you  have  an 
XML  file,  you  can  use  it  like  any  data  source  and  create  a  DataSet  out  of  it. 

In  ADO.NET,  XML  is  a  fundamental  format  for  data.  The  ADO.NET  data 
Application  Protocol  Interfaces  (API)  automatically  create  XML  files  or  streams  out  of 
information  in  the  DataSet  and  send  them  to  another  component.  The  second  component 
can  invoke  similar  APIs  to  read  the  XML  back  into  a  DataSet.  The  data  is  not  stored  in 
the  DataSet  as  XML — for  example,  you  cannot  parse  data  in  a  DataSet  using  an  XML 
parser  but  instead,  in  another  more  efficient  format. 

Basing  data  protocols  around  XML  offers  a  number  of  advantages:  1)  XML  is  an 
industry-standard  format.  This  means  that  your  application's  data  components  can 
exchange  data  with  any  other  component  in  any  other  application,  as  long  as  that 
component  understands  XML.  Many  applications  are  being  written  to  understand  XML, 
which  provides  an  unprecedented  level  of  exchange  between  disparate  applications. 

XML  is  text-based.  The  XML  representation  of  data  uses  no  binary  information, 
which  allows  it  to  be  sent  via  any  protocol,  such  as  HTTP.  Most  firewalls  block  binary 
information;  however,  by  formatting  information  in  XML,  components  can  still  easily 
exchange  information. 
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2. 


SCHEMA  DEFINED  DATA  STRUCTURES 


ADO.NET  uses  XML  directly  when  working  with  metadata.  Here,  DataSets  are 
represented  as  XML.  The  structure  of  the  DataSet — the  definition  of  what  tables, 
columns,  data  types,  constraints,  and  so  on  are  in  the  DataSet — is  defined  using  an  XML 
Schema  based  on  the  XML  Schema  Definition  language  (XSD).  Just  as  data  contained 
by  a  DataSet  can  be  loaded  from  and  serialized  as  XML,  the  structure  of  the  DataSet  can 
be  loaded  from  and  serialized  as  XML  schema. 

The  ADO.NET  DataSet,  represented  in  Ligure21,  is  a  data  construct  that  can 
contain  several  relational  rowsets,  the  relations  that  link  those  rowsets,  and  the  metadata 
for  each  rowset.  The  DataSet  also  tracks  which  fields  have  changed,  stores  their  new 
values,  original  values,  and  custom  information  in  its  Extended  Properties  collection. 
The  DataSet  can  be  exported  to  XML  or  created  from  an  XML  document,  thus  enabling 
increased  interoperability  between  applications.  (MSDN  Library) 


Ligure21.  ADO.NET  DataSet 
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3. 


DATA  CACHING  IN  DATASETS 


The  most  common  data  task  is  to  retrieve  data  from  the  database  and  do 
something  with  it  such  as  display  it,  process  it,  or  send  it  to  another  component. 
Frequently,  the  application  needs  to  process  not  just  one  record  but  a  set  of  them;  for 
example,  a  list  of  sailors  or  Billet  Sequence  Codes  (BSC).  Often  the  set  of  records  that 
the  application  requires  comes  from  more  than  one  table  such  as  Sailors,  Systems, 
Assigned  Aircraft,  and  other  similar  sets  of  related  records  as  referenced  in  Prometheus. 
(MSDN  Library) 

Once  these  records  are  retrieved,  the  application  typically  works  with  them  as  a 
group.  For  example,  the  application  might  allow  the  user  to  browse  through  all  the 
SAILOR  records  and  examine  their  assigned  BSC  for  one  or  more  Sailors,  then  move  to 
the  next  BSC  and  reassign  a  new  BSC,  and  so  on.  (MSDN  Library) 

In  the  domain  of  Prometheus,  it  is  impractical  to  go  back  to  the  database  each 
time  the  application  needs  to  process  the  next  record.  Doing  so  would  undo  much  of  the 
advantages  gained  by  minimizing  the  need  for  open  connections.  The  Prometheus 
application  therefore,  works  with  a  temporary  cache  of  records  retrieved  from  the 
database  and  connects  to  the  database  only  when  required. 

A  DataSet  is  a  cache  of  records  retrieved  from  a  data  source.  It  works  like  a 
virtual  data  store.  A  DataSet  includes  one  or  more  tables  based  on  the  tables  in  the  actual 
database,  and  it  can  include  information  about  the  relationships  between  those  tables  and 
constraints  on  what  data  the  tables  can  contain. 

Contained  in  the  DataSet  is  usually  a  reduced  version  of  what  the  database 
contains.  However,  the  DataSet  can  be  worked  with  in  much  the  same  way  as  the  real 
data.  While  doing  so,  the  DataSet  remains  disconnected  from  the  database,  which  frees  it 
to  perform  other  tasks. 

You  often  need  to  update  data  in  the  database,  although  not  nearly  as  often  as  you 
retrieve  data  from  it.  You  can  perform  update  operations  on  the  DataSet,  and  these  can 
be  written  to  the  underlying  database. 
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An  important  point  is  that  the  DataSet  is  a  passive  eontainer  for  the  data.  To 
retrieve  data  from  the  database  and  write  it  baek,  you  use  data  adapters.  A  data  adapter 
eontains  one  or  more  data  eommands  used  to  populate  a  single  table  in  the  DataSet  and 
update  the  eorresponding  table  in  the  database.  A  data  adapter  typieally  eontains  four 
eommands,  one  eaeh  to  seleet,  insert,  update,  and  delete  rows  in  the  database.  Therefore, 
a  data  adapter's  Fill  method  might  execute  a  SQL  statement  such  as  select  sid, 
LastName,  FirstName  FROM  SAILORS  whenever  the  method  is  Called. 

Because  a  DataSet  is  effectively  a  private  copy  of  the  database  data,  it  does  not 
necessarily  reflect  the  current  state  of  the  database.  If  you  want  to  see  the  latest  changes 
made  by  other  users,  you  can  refresh  the  DataSet  by  calling  the  appropriate  Fill  method. 

One  of  the  advantages  of  using  DataSets  is  that  components  can  exchange  them  as 
required.  For  example,  a  business  object  in  the  middle  tier  might  create  and  populate  a 
DataSet  then  send  it  to  another  component  elsewhere  in  the  application  for  processing. 
This  DataSet  property  means  that  components  do  require  individual  queries  of  the 
database  to  retrieve  related  data.  (MSDN  Library) 


D.  PROMETHEUS  CORE  FUNCTION  WALKTHROUGH 

1.  Import  of  the  AMD  and  EDVR  Text  Files 

Importing  the  AMD  &  EDVR  text  files  via  the  Import  Wizard  is  the  preferred 
method  of  updating  and  maintaining  the  E-Pro  Alpha.mdb  database  with  the  most  current 
information  available.  Eigure  22  is  an  Import  Wizard  screenshot. 

Prometheus  can  handle  multiple  imports  of  the  same  or  dissimilar  files.  Imported 
files  can  be  undone  during  the  file  verification  process  and  are  not  permanent  until  the 
user  has  specifically  accepted  them.  Once  imported,  the  user  can  change  properties  via 
many  input  methods. 

The  Enlisted  Placement  Management  Center  (EPMAC)  is  the  advocate  for  the 
distribution  of  active  duty  personnel  to  enhance  the  manning  readiness  of  surface, 
submarine,  aviation  and  ashore  units.  EPMAC  provides  a  self-extractable  file,  formatted 
as  UIC.exe  (i.e.  #####. exe).  An  authorized  user  of  the  EPMAC  Bulletin  Board  System 
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(BBS)  must  download  this  file  via  the  WildC.A.T  Navigator  program.  WildC.A.T. 
Navigator  is  a  simple  telnet  terminal  elient  used  to  eonneet  to  the  EPMAC  BBS  and 
transfer  requested  files  to  the  user. 

After  the  UIC.exe  file  download,  and  the  user  has  extraeted  the  AEEDVR.txt  file, 
the  following  importation  example  applies. 

Step  1.  Launeh  the  Import  AMD/ED VR  Wizard.  Erom  the  Tools  menu, 
select  Import  AMD/EDVR.  The  Import  AMD/EDVR  Wizard  will 
automatically  load  with  default  values  selected  and  display  a  welcome  screen. 
Click  Next  >  to  continue  the  wizard 


Eigure  22.  Import  Wizard  Welcome  Screen 

Step  2.  Choose  the  type  of  text  file  you  are  importing.  Valid  choices  are 
the  AMD  or  EDVR  text  files.  Click  Next  >  to  continue  and  the  import  wizard 
will  display  the  fide  type  selection  dialog. 

Step  3.  When  the  Verify  Eile  Dialog  Window  opens,  the  wizard  will 
attempt  to  locate  the  file  in  its  default  location.  Eor  the  EDVR  file,  it  looks  in 
the  following  order: 

1.  C:\Program  Piles\PCEDVR\Import\AEEDVRBB.txt 

2.  %Install  Prometheus  Directory%\Import\EDVR\AEEDVRBB.txt 
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3.  The  last  known  location  where  the  file  was  previously  opened. 

NOTE:  If  the  file  is  found,  the  Import  Wizard  will  enable  the  Next  >  button 
for  you  to  continue.  If  the  file  is  NOT  found,  or  you  wish  to  change  the 
location  of  the  file,  you  must  select  the  New  Connection  button,  where  you 
much  select  a  new  source  file  to  be  imported. 

Step  4.  Next,  you  must  set  up  any  preferences  for  importing  the  file.  You 
will  be  stepped  through  two  screens.  After  you  have  made  your  choices,  click 
the  Finish  button  to  begin  importing  records. 

NOTE:  At  the  end  of  the  wizard,  regardless  of  your  choices,  you  can  undo, 
reject,  or  accept  any  additions  made  to  the  file  prior  to  saving  data  to  your 
database. 

Step  5.  The  Import  Wizard  will  import  and  format  ED VR  data.  When 
complete,  you  will  be  notified  and  must  click  the  Next  >  button  to  finish  the 
wizard  and  load  the  EDVR  Verification  Window  where  you  can  view,  edit, 
accept  or  reject  the  imported  records  as  a  group  or  individually. 

The  Activity  Manning  Document  (AMD)  is  the  single  authoritative  source  for  an 
activity’s  statement  of  manpower  requirements  (SMR)  and  manpower  authorizations 
allocated  to  perform  assigned  missions.  Navy  Training  and  Management  Planning 
System  (NTMPS)  at  Pensacola,  Elorida  provides  access  to  their  manpower  databases  via 
the  Citrix©  Independent  Computing  Architecture  (ICA)  Client.  Prometheus  provides  a 
formatted  query  to  be  used  by  an  authorized  user  of  the  NTMPS  database.  This  file 
produces  the  AMD.txt  file  required  for  the  AMD  import  wizard.  Once  the  query  file  is 
ran  on  the  NTMPS  database  via  Citrix  ICA  Client,  the  created  query  file  can  be  stored 
locally  and  imported  similarly  to  the  EDVR  example. 

2.  Assisted  Assignment  of  the  BSC  to  the  Sailor  Record 

Billet  Sequence  code  assignment  is  a  primary  function  of  the  AMO.  The  Activity 
Manning  Document  is  the  single  authoritative  source  for  an  activity’s  Statement  of 
Manpower  Requirements  (SMR)  and  manpower  authorizations  allocated  to  perform 
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assigned  missions.  More  importantly  to  users,  the  AMD  houses  their  command's 
applicable  Billet  Sequence  Codes  (BSC). 

The  AMD  text  file  must  be  imported  via  the  Import  AMD/ED VR  Function  prior 
to  assigning  BSCs  to  your  personnel.  Until  a  successful  import  has  taken  place,  the 
available  BSCs  will  be  blank.  See  how  to  Import  the  AMD  into  Prometheus  for  more 
details.  Prometheus  provides  two  methods  for  assigning  BSCs  to  a  Sailor. 
a.  Single  Sailor  Record  Assignment 

Figure  23  illustrates  the  data  form  provided  for  assigning  a  BSC  to  a 
single  SAIFOR  record. 


Figure  23.  BSC  Assignment  Form 

Advantages; 

•  Simple  edit  of  single  record  in  an  easy-to-use  interface. 

•  Records  are  sorted  alphabetically  by  Fast  Name. 

•  Only  available  BSCs  are  displayed  based  on  your  choice  of  Rate, 
Rating,  or  NEC. 

•  Assistance  tools  are  made  available  for  your  convenience. 
Disadvantages: 

•  You  must  assign  a  BSC  to  each  sailor  individually. 
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If  there  are  many  sailors,  you  must  still  assign  the  BSC 
individually. 


b.  Multiple  Sailor  Record  Assignment 

Figure  24  illustrates  the  data  grid  for  assigning  BSCs  to  all  Sailors. 


Figure  24.  BSC  Assignment  Data  Grid 


Advantages: 

•  Edit  multiple  reeords  at  once  in  an  easy-to-use  interface. 

•  Sort  multiple  records  by  your  own  preferences. 

•  Fast  and  effective  means  for  editing  numerous  records  at  once. 
Disadvantages: 

•  You  must  assign  a  BSC  ID  (chosen  from  a  list)  to  each  sailor. 

•  There  is  no  error  checking  for  assigning  an  unqualified  sailor  to  a 

particular  BSC. 

3,  NEC  Data,  M-Rating  and  T-Rating 

Manning  Rating  (M-Rating)  refers  to  the  quantity  of  personnel  Current-On-Board 
per  Billets  Assigned  (COB/BA).  Training  Rating  (T-Rating)  references  a  sailor’s  training 
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level  and  years  of  experienee  in  their  eurrent  NEC.  Figure  25  illustrates  the  primary  data 
form  used  for  viewing  and  printing  NEC  and  rating  datum  ealeulations. 


Figure  25.  NEC/Rating  View/Print  Form 

The  primary  data  form,  Prometheus  -  Rating  Reports  &  Views,  incorporates  three 
primary  tools  for  user  interaction  with  the  database;  Save/Export  Data  to  Excel,  Print 
NEC  and  Rating  Views  and  Edit  NEC  Data. 

4,  M-RATING  COMPUTATION 

Prometheus  accomplishes  the  M-Rating  calculation  for  a  specific  activity  by 
evaluating  the  number  of  personnel  onboard  and  comparing  that  information  to  the 
authorized  billets  assigned  to  that  activity.  Prometheus  provides  two  options  for 
displaying  M-Rating  datum  calculations:  by  period  (nine-month  projection)  and  by 
aircraft  type.  Prometheus  uses  the  following  simplified  algorithm  to  accomplish  this 
comparison; 

a)  Check  each  record’s  values  for  COB  and  BA  (Yes  =  1,  No  =  0)  and 
record  these  values  to  a  corresponding  System  and  Aircraft  type. 
These  values  are  stored  in  a  3 -dimension  array.  The  3 -dimension  array 
allocates  record  keeping  space  for  14  system  types,  10  aircraft  types, 
and  COB  and  BA  values  for  each  record. 
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b)  Prometheus  ehecks  desired  output  type — by  period  or  by  aireraft  type. 
If  by  period,  Prometheus  permits  only  one  aircraft  type.  Prometheus 
therefore  calculates  a  ten-month  projection.  Note:  these  values  equate 
to  POBl  through  POB9  where  the  tenth  value  is  the  actual  COB  of 
today’s  date.  If  by  aircraft  type,  Prometheus  dimensions  each  system 
type  to  its  corresponding  aircraft  type. 

c)  Prometheus  evaluates  the  stored  values  in  the  3-dimension  array  and 
calculates  the  M-Rating.  Prometheus  then  inserts  these  M-Rating 
calculations  into  a  datagrid  object  on  the  M-Rating  View  tab. 

The  user  initiates  the  M-Rating  and  T-Rating  calculations  when  the  form  is 
loaded.  Note:  During  testing  of  the  function,  only  a  small  fraction  of  the  sailors  were 
assigned  BSCs. 

5.  T-RATING  COMPUTATION 

The  T-Rating  computation  was  not  a  requirement  of  the  Prometheus  application, 
though  we  have  incorporated  it  as  a  potential  future  program  option.  The  T-Rating 
computation  is  average  score  given  to  each  system  of  a  particular  aircraft  over  a  nine- 
month  projection.  Each  record  or  sailor’s  score  relates  to  these  current  standards:  T-1 
equates  to  NEC  awarded  plus  two  years  of  experience;  T-2  equates  to  NEC  awarded  plus 
six  months  of  experience;  T-3  equates  to  NEC  awarded;  T-4  equates  to  no  NEC  or 
incorrect  NEC  awarded. 

E.  SUMMARY 

Prometheus  is  a  distributed,  front-end  database  client  application  that  utilizes  the 
Microsoft©  .NET  Eramework  and  Visual  Basic  .NET  to  meet  its  development  needs.  At 
the  heart  of  the  Prometheus  application  is  ActiveX  Data  Objects  for  the  .NET  Eramework 
(ADO.NET).  ADO.NET  is  a  set  of  classes  that  expose  data  access  services  to  the  .NET 
programmer.  Utilization  of  sound,  object  oriented  ADO.NET,  and  .NET  practices  will 
afford  the  Prometheus  application  easy  portability  to  a  middle-tier  business  object  that 
can  be  readily  integrated  into  a  professional  n-tiered  business  model. 
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ADO.NET  was  designed  to  meet  the  needs  of  this  new  programming  model; 
disconnected  data  architecture,  tight  integration  with  XML,  common  data  representation 
with  the  ability  to  combine  data  from  multiple  and  varied  data  sources,  and  optimized 
facilities  for  interacting  with  a  database,  all  native  to  the  .NET  Eramework.  (MSDN 
Library)  This  chapter  outlined  the  fundamental  components  and  object  models  of 
ADO.NET  employed  in  the  Prometheus  application,  as  well  as  give  a  brief  explanation  of 
data- access  and  data  handling  through  ADO.NET  and  XML  resources  within  the  .NET 
Eramework. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

As  a  result  of  this  study,  we  have  arrived  at  conclusive  answers  to  questions 
presented  in  Chapter  I. 

As  circumstances  currently  stand  today,  gaining  knowledge  regarding  the 
status  of  manpower  within  an  activity  is  a  manual,  complex,  and 
cumbersome  process.  Would  it  be  possible  to  develop  an  application  that 
could  automatically  read  and  import  data  from  an  activity’s  EDVR  and 
compare  it  with  the  standing  AMD  at  various  milestone  points  of  a 
deployment/turnaround  cycle  to  produce  a  report  of  overall  T-Ratings  (a 
rating  based  on  an  individuals  training  level  and  years  of  experience  in 
current  Navy  Enlisted  Classification  (NEC)  Code)  and  M-Ratings  (a 
simple  Current  On  Board  (COB)  per  Billets  Assigned  (BA))  for 
individuals  within  the  command? 


The  answer  to  this  question  is  yes  as  evidenced  by  the  Prometheus  application 
developed  in  this  thesis.  By  using  the  EDVR  and  AMD  databases  that  currently  exist,  we 
were  able  to  develop  an  application  that  pulls  only  the  data  required  in  completing 
specific  processes  and  functions.  How  this  development  differs  from  existing 
applications  such  as  PC-EDVR  and  NTMPS’  electronic  AMD  is  that  the  user  can  now 
combine  information  from  the  two  reports  automatically  in  order  to  perform  analysis  that 
before  had  to  be  processed  manually  on  paper.  While  the  ability  to  import  NEC  Award 
Dates  from  EPMAC’s  database  was  not  incorporated  in  this  prototype,  it  would  not  be 
impossible  to  incorporate  such  a  process.  Eor  now,  the  user  will  simply  have  to  perform 
NEC  Award  Date  verification  as  they  had  previously  done  and  then  input  that  data  to 
Prometheus  in  producing  T-Rating  Calculations. 

If  so,  can  the  M-rating  for  each  Type/Model/Series  and/or  system  be 
computed  and  evaluated  automatically? 

We  have  been  able  to  calculate  the  M-Rating  for  the  activity  by  evaluating  the 
quantity  of  personnel  onboard  and  comparing  that  information  to  the  billets  that  have 
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been  assigned  to  that  aetivity.  More  speeifieally,  two  options  are  given:  one  by  period 
(nine  month  projeetion)  and  the  other  by  aireraft  type. 

Next,  eheeks  of  COB  (Y/N)  and  then  the  date  for  EDA/L  to  see  whether  the 
person  filling  the  BSC  will  be  on  board  in  the  next  nine  months  are  performed.  These  are 
ealled  POBl  through  POB9.  Eaeh  gets  a  one  for  yes  or  zero  for  no.  A  eheek  of  BA  for 
the  BSC  and  a  mateh  for  the  PNEC  and  the  BNEC  (of  the  BSC  -  from  AMD)  is  made. 

A  3 -dimension  array  (two  are  ereated  here)  is  ereated  and  filled  with  the 
aeeumulative  data  eonsisting  of  the  following:  fourteen  systems,  ten  aireraft,  and  two 
quantities  (BA  &  COB/POBl-9).  The  results  produeed  are  1)  the  total  number  of 
systems  per  aireraft  and  2)  whether  they  are  COB  and  filling  an  authorized  billet  (BA). 

The  period  method  simply  ealeulates  one  aireraft  type  and  all  14  systems,  and 
then  evaluates  the  resulting  projeetion  out  to  9  months. 

Can  a  seeure  web-based  interfaee  applieation  be  developed  for  the  user  to 
interfaee  with  the  database  via  the  use  of  the  World  Wide  Web? 

Although  not  a  requirement  in  the  development  of  this  applieation,  with  the 
further  expansion  and  inereased  use  of  the  Navy-Marine  Corps  Internet  infrastrueture,  the 
next  logieal  extension  of  this  development  is  web-enablement  and  the  potential  of  being 
able  to  perform  the  same  funetions  done  in  Prometheus  via  the  Internet.  This  would  add 
to  the  real-time  funetionality  of  manpower  management  as  well  as  allow  detaehed  or 
deployed  aetivities  to  make  ehanges  or  updates  as  they  oecur.  Eor  this,  minor  alterations 
would  be  required  to  the  interfaees  for  the  web  as  well  as  the  ineorporation  of  additional 
seeurity  measures  sueh  as  eneryption  and  file  proteetion.  Eirewall  issues  with  Navy 
Network  Operation  Centers  and  base  eommunieations  would  also  require  investigation. 

Is  it  possible  to  use  a  eentral,  unified  database  for  data  input/output, 
storage,  proeessing  and  arehiving  of  data  to  meet  manpower  management 
requirements  so  that  the  manager  ean  make  the  best  deeisions  afforded 
him  at  any  given  time? 

This  issue  may  be  addressed  by  the  establishment  of  a  seeure  database  server  to 

house  the  manpower  data  for  a  group  of  aetivities.  Issues  sueh  as  whieh  aetivities  to 
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group,  where  to  loeate  servers,  how  long  to  store  aetivity  data  and  assoeiated 
maintenanee  may  be  addressed  through  the  review  and  analysis  of  requirements  and 
needs  of  the  users  of  the  system. 


B,  RECOMMENDATIONS 

1.  Follow  On  Thesis  Projects  To  Include: 

a.  Multiple  Thesis  Submissions 

To  further  the  study  and  development  of  this  applieation  as  well  as 
applieability  to  other  aetivities,  additional  theses  on  this  subjeet  need  to  be  promoted  and 
eoordinated.  The  result  of  this  thesis  has  been  targeted  to  a  very  narrow  range  of  funetion 
and  applieations.  On  a  mueh  broader  seale,  thesis  teams  eould  foeus  on  different  sub- 
areas  and  eombine  the  work  into  one  overarehing  projeet.  Possible  thesis  topies  that 
eould  be  researehed  are  eonversion  of  the  Navy’s  flat  database  file  systems  to  a  relational 
database  strueture;  use  of  On  Line  Analytieal  Proeessing  (OLAP)  eapabilities;  and  eareer 
assignment,  training,  and  management  based  on  a  eentralized,  multidimensional  database. 
It  is  not  neeessary  for  all  researeh  that  is  eondueted  to  beeome  part  of  the  working 
projeet,  but  this  additional  researeh  will  only  add  to  development  of  the  best  solution 
possible. 

b.  Adaptation  of  NEC  Award  Date  Report 

The  software  development  proeess  performed  in  this  thesis  has  been  very 
enlightening,  while  at  the  same  time  humbling.  Many  of  the  proeesses  involved  were 
found  to  demand  greater  time  and  effort  than  originally  antieipated — something  anyone 
who  has  worked  on  a  projeet  understands.  The  funetion  of  NEC  Award  Date  verifieation 
simply  beeame  a  vietim  of  time  eonstraints  in  this  ease.  Intentions  for  this  matter  were  to 
perform  similar  data  imports,  as  with  the  EDVR  and  AMD,  then  ineorporate  these  data 
for  use  in  ealeulations  of  the  T-Rating,  thereby  eliminating  the  manual  and  very  time- 
eonsuming  steps  that  an  AMO  eurrently  performs  in  generating  this  information.  One 
potential  limitation  here  however,  was  that  we  have  based  our  theory  on  the  assumption 
that  a  NEC  Award  Date  report  would  be  produeed  and  published  by  EPMAC  Code  49  for 
eaeh  UIC. 
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2.  Changes  to  Existing  Manpower  Database  Systems 

Currently,  the  development  of  Prometheus  is  limited  to  a  elient-side  application. 
Ideally,  Prometheus  should  connect  to  a  central  database  located  on  the  NMCI  and  poll 
data  remotely.  The  problem  exists  where  the  manpower  manager  must  download  his  data 
via  legacy  software  from  different,  remote  data  sources.  Prometheus  is  built  on  a 
disconnected  data  model  that  uses  snapshots  of  data  that  are  isolated  from  the  data 
source.  Through  NMCI,  Prometheus  or  similar  applications  can  adopt  an  N-tier  solution 
where  they  connect  to  a  central  database  and  query  the  required  data  directly  from  the 
source.  Ultimately,  this  solution  would  cut  out  the  disparity  and  increase  reliability  of 
data  accuracy  and  availability. 


C.  FUTURE  ENHANCEMENTS 

1.  XML-based  Web  Service  Application 

We  are  entering  the  next  phase  of  application  development — a  phase  enabled  by 
the  internet  and  the  concept  of  web  services.  A  web  service  is  an  application  that  exposes 
its  features  programmatically  over  the  internet  using  standard  internet  protocols.  The 
move  away  from  complex  distributed  applications  to  the  creation  of  power  applications 
that  can  be  used  by  anyone,  anywhere,  increases  the  reach  of  applications  and  enables 
true  uninterrupted  service  to  all  users.  XML-based  web  services  facilitate  the  idea  of 
tightly  coupled,  highly  productive  aspects  of  N-tier  computing  with  the  loosely  coupled, 
message-oriented  concepts  of  the  web. 

Ideally,  the  next  generation  of  manpower  management  tools  should  embrace  the 
move  to  internet  ready,  XML-based  web  services.  This  would  allow  users  access  at 
anytime  to  data  resources  anywhere  connectivity  exists. 

2.  NMCI 

The  Navy  Marine  Corps  Intranet  (NMCI)  affords  the  rare  opportunity  to  enable 
web-based  applications  to  exist  throughout  the  Department  of  the  Navy.  This  promises 
continuity  and  standardization  of  Navy  business  practices,  most  notably  in  the  scope  of 
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this  thesis:  manpower  management.  One  of  the  primary  eoneerns  when  developing  the 
Prometheus  projeet  was  its  straightforward  transition  to  a  web-based  applieation.  Future 
generations  of  manpower  management  software  must  be  fully  supported  and 
administered  under  the  NMCI  eontraet.  Under  both  the  NMCI  infrastrueture  and  a 
managed,  eentralized  database,  sueh  manpower  applieations  would  greatly  enhanee  the 
produetivity  of  manpower  managers  and  the  availability  of  standardized,  fully  funetional 
management  tools. 

3,  Security 

The  eurrent  beta  release  of  the  Prometheus  management  software  does  not 
address  seeurity  eoneerns  or  requirements.  Seeurity  of  sensitive  information  is  indeed 
paramount  and  future  releases  of  manpower  management  software  must  reeognize  and 
adhere  to  sound  seeure  software  development  praetiees.  There  are  varieties  of  seeurity 
resourees  that  must  be  in  today’s  server-side  applieations.  Future  manpower  solutions 
ean  reduee  vulnerabilities  only  by  following  good  seeurity  design  praetiees  and  properly 
using  seeurity  teehnologies. 

It  is  reeommended  that  the  next  generation  of  manpower  software  exist  as  a  web- 
based  serviee.  As  sueh  it  is  also  reeommended  that  the  applieation  utilize  the  Mierosoft 
Web  Serviees  Seeurity  (WS-Seeurity).  Mierosoft  offers  the  Web  Serviees  Development 
Kit  (WSDK)  Teehnology  for  implementing  seeurity  features  from  within  the  applieation. 
The  WSDK  sits  on  top  of  the  Mierosoft  .NET  Framework  support  for  writing  and 
eonsuming  web  serviees.  This  is  the  first  toolset  that  implements  seeurity  within  a 
Simple  Objeet  Aeeess  Protoeol  (SOAP)  message.  By  taking  advantage  of  WS-Seeurity 
for  authentieating  and  signing  data  (i.e.  authentieation,  integrity  verifieation,  and 
eneryption  from  within  the  SOAP  envelope),  the  next  generation  of  manpower 
applieations  will  no  longer  be  tied  to  strietly  using  the  seeurity  eapabilities  of  the 
underlying  transport  and  be  inherently  more  seeure. 

Beyond  the  simple  seeurity  of  information  as  it  is  transferred  to  and  from  the 
elient,  the  questions  of  user  authentieation  and  aeeess  must  also  be  addressed.  The  .NET 
Eramework’s  role-based  seeurity  features  provide  a  robust  solution  for  implementing 

role-based  seeurity  features  into  future  manpower  applieations.  The  manpower 
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application  should  incorporate  role-based  seeurity  features  to  enforce  business  polieies 
and  data  integrity  where  the  management  of  user  aeeess  is  done  separately  from  the 
proeesses  of  the  applieation  itself 

4.  Additional  Sub  form  Interfaces  and  Print  Functions 

Due  to  the  scope  of  this  project  and  the  time  constraints  involved  in  development, 
several  promising  features  were  not  ineorporated  into  this  release  of  Prometheus.  Future 
releases  of  Prometheus  or  other  manpower  solutions  should  inelude  the  implementation 
of  the  following  reeommendations: 

a.  Drop  down  lists  that  display  desired  data  in  a  clear  and  intuitive  style.  This 
would  help  assure  preeise  and  aeeurate  data  entry,  remove  eonfusion  as  to  the 
proper  data  format,  and  assist  in  simplifying  data  validation. 

b.  Print  preview  for  all  printable  datum  and  reports. 

e.  Email  funetion  for  electronie  submission  of  reports  and  datum. 

d.  Future  versions  of  Prometheus  should  ineorporate  a  wider  range  of  reports  and 
forms  for  every  user  category  aeross  the  Department  of  the  Navy.  As  beta 
testing  evolves,  feedbaek  from  manpower  managers  will  be  essential  to 
developing  a  robust  and  useful  applieation  that  ean  meet  the  needs  of  a  range 
of  end  users. 


D,  PROTOTYPE  DEMONSTRATION 

On  1 1  September  2002,  the  Prometheus  manpower  management  applieation  was 
demonstrated  at  Commander  Strike  Fighter  Wing  Paeifie,  Naval  Air  Station  Femoore, 
CA.  The  Wing  Assistant  Maintenanee  Offieer  (N42A),  Wing  Manpower  Manager 
(N13A),  and  three  squadron  AMO’s,  FT  Bob  Henley,  FT  Allen  Ford  and  CWO  Derriek 
Franekowiak  graeiously  volunteered  time  to  view  the  developed  applieation  and  provide 
us  with  feedbaek.  As  a  result  of  this  demonstration,  areas  for  added  funetionality  were 
noted.  Speeifieally,  implementation  of  a  BA  to  COB  and  BA  to  NMP  eomparison  in 
order  to  ealeulate  manning  levels  would  be  greatly  inerease  the  applieation’ s  value. 
Additional  comments  received  were  positive  and  supportive  of  further  study  and 
development  of  this  type  of  applieation. 
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E,  SUMMARY 

Manpower  management  within  all  aetivities  of  the  United  States  Navy  has 
traditionally  been  an  extremely  ehallenging  funetion.  Careful,  crueial  reeoneiliation  of 
manpower  reports  sueh  as  the  EDVR  and  the  AMD  are  a  eritieal  event  in  the  proper 
exeeution  of  sueh  a  proeess.  Unfortunately,  an  automated  proeess  where  sueh  a  manual, 
regularly  oeeurring,  time  eonsuming,  error  prone,  man-hour  intensive  routine  is 
performed  does  not  eurrently  exist.  Speeifieally,  in  the  area  of  Capability  Ratings, 
Manning,  Training,  Equipment  and  Supplies,  an  aetivity  should  be  able  to  extract  a 
prescribed  range  of  data  from  their  EDVR  and  AMD.  Then  have  it  automatically 
calculate  the  T-Rating  for  each  individual  at  various  milestone  points  of  a  deployment 
turnaround  cycle  and  produce  a  report  of  an  overall  T-Rating  and  M-Rating  as  required 
by  the  Eunctional/Type  Wing  Commander.  This  thesis  is  an  attempt  to  address  these 
issues.  The  feasibility  and  requirements  for  such  an  automated  software  application  have 
been  proven.  The  application  developed  in  this  thesis  has  been  able  to  achieve 
successfully,  reconciliation  of  the  EDVR  and  AMD  within  a  single  processing 
environment.  While  Prometheus  is  only  a  prototype,  it  illustrates  that  a  solution  to  the 
manpower  management  problem  of  complexity  and  disintegrated  databases  exists  and 
should  be  further  developed  on  a  much  larger  scale  for  all  aviation  squadrons  as  well  as 
all  activities  within  the  Navy. 
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APPENDIX  A  MAPMIS  DECISION  LOGIC  TABLE 


ENLISTED  DISTRIBUTION  AND  VERIFICATION  REPORT  (EDVRMAN) 
SECTION  15.  MAPMIS  DECISION  LOGIC  TABLE  -  ENLISTED 


ACTION 

REFERENCE 

REMARKS 

D 

F 

L 

M 

DJMS  PTG 

EVENT 

M 

o 

E 

E 

(unless  otherwise  stated) 

R 

R 

T 

s 

S 

M 

T 

s 

E 

A 

S 

R 

G 

D 

S 

E 

Active  Duty  Obligation,  correction  of  EDVR 

X 

MILPERSMAN  5040100 
DMRSMAN 

Ltr  to  NAVPERSCOM  (NPC-312) 

Active  Duty  Service  Date,  correction  of  EDVR 

X 

SDS  PPG  Chapter  5. 

Request  Statement  of  Service  from 

Section  B 

NAVPERSCOM  (NPC-312F) 

DMRSMAN 

if  necessary 

Administratively  dropped  from  Navy  strength 

X 

SDS  PPG  Chapter  3. 

accounts 

Section  D 

DMRSMAN 

Advancement  Effective  Date,  correction  of 

X 

EDVRMAN 

NAVPERSCOM  (NPC-312G) 
with  substantiating  paperwork 
(l.e..DD4.  pages  4  and 9) 

Appointment  to  Officer  Candidate  School 

Part  1 .  Chapter  2 

No  Enlisted  Diary  Action  Is  necessary. 

(OCS).  Aviation  Officer  Candidate  (AOC), 

NAVPERSCOM  (NPC-312G)  Will 

Warrant  Officer.  Limited  Duty  Officer  (LDO). 
Naval  Academy 

remove  from  EDVR 

Appointment  to  officer  candidate  status  in  other 

X 

Part  1 .  Chapter  3 

USN  discharge  as  appropriate 

service  academy  (l.e..  Army.  Air  Force,  or 

Coast  Guard)  and  NROTC  Proaram 

DMRSMAN 

Assianed  rate,  correction  of  EDVR 

X 

EDVRMAN 

Ltr  to  placement  officer  at  EPMAC 

Branch/Class,  correction  of  EDVR 

X 

SDS  PPG  Chapter  5. 

Not  to  be  used  to  Correct  Contract 

Section  B 

DMRSMAN 

Errors 

Citizenship,  change/correction  of  EDVR 

X 

SDS  PPG  Chapter  5. 
Section  B 

DMRSMAN 

Confinement 

X 

Part  7.  Chapter  5 

NAVPERS  1070/607 

Date  received,  change 

X 

SDS  PPG  Chapter  2. 
Section  E 

DMRSMAN 

Death,  reporting  of 

X 

MILPERSMAN  1770-010 

MSG  to  NAVPERSCOM  (NPC-621), 

Dependent(s).  change  number  of 

X 

Part  3  .  Chapter  2 

NAVPERS  1070/602.  Parti 

Dependent(s),  correction  of 

X 

X 

Part  3,  Chapter  2 

Forward  certified  copy  of  NAVPERS 

1070/602  to  DPAS  Code  PMA.  Do 
not  forward  if  DFAS  Code  FMASC  has 
not  determined  DEPN  status 

Dependent(s)  on  station  {Collocation  data). 

X 

X 

Part  1  .  Chapter  4 

Reporting  Endorsement 

reDOrtIna  of 

DMRSMAN 
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EDVRMAN 
01  MAR  W 


EVENT 

ACTION 

REFERENCE 

DJMS  PTG 

(unless  othePMse  stated) 

REMARKS 

D 

M 

R 

S 

s 

D 

S 

F 

0 

R 

M 

L 

E 

T 

T 

E 

R 

M 

E 

S 

S 

A 

G 

E 

Dependent(s)  on  station  (Collocation  data), 
change  number  of 

X 

SDS  PPG  Chapter  5. 
Section  B 

DMRSMAN 

Deserter,  reporting  of 

X 

X 

MILPERSMAN  1600-060 
(Also  refer  to  Part  1. 

Chapter  2  for  items 
required  to  be  reported  on 
NAVPERS  1070)606  In 
connection  with  Desertion) 

MSG  to  NACIC  Great  Lakes,  IL.  info 
copy  to  NAVPERSCOM  (NPC-842). 
DFASand  EPMAC. 

Deserter,  return  of 

X 

X 

MILPERSMAN  1600-050 

MSG  to  NACIC  Great  Lakes.  IL.  info 
copy  to  NAVPERSCOM  (NPC-842),  DFAS 
and  EPMAC  .  NAVPERS  1070/606. 

1070/607 

Designator,  change 

X 

SDS  PPG  Chapter  5. 
Section  B 

DMRSMAN 

Diary  corrections,  general 

X 

SDS  PPG  Chapter  5. 
Section  B 

DMRSMAN 

Discharge 

X 

X 

Part  1 .  Chapter  3 
DMRSMAN 

Detaching  Endorsement 

Distribution  NEC.  change 

X 

X 

EDVRMAN 

DMRSMAN 

DMRS  transaction  to  EPMAC  or 
compiete  NEC  Discrepancy  Report 

Duty  Status,  change 

X 

SDS  PPG  Chapter  5  . 
Section  B 

DMRSMAN 

Use  TAC  376  to  change  ACC  3XX  to 
1XX/3XX  or  105  to  381  or  1XX  to  393.  Use 
TAC  CHACC  for  aii  other  ACC  changes. 

Education  level,  change 

X 

SDS  PPG  Chapter  5, 
Section  C 

DMRSMAN 

Ethnic  Group  Designator,  correction  of 

X 

SDS  PPG  Chapter  5. 
Section  B 

DMRSMAN 

Exceptional  Family  Member 

X 

OPNAVINST  1754.2 

Submit  itr  to  NAVPERSCOM 
(NPC-662F)  to  remove  from  the  EFM 
program.  Submit  documents  per  the 
OPNAViNST  1754.2  for  enroiiment 
in  the  proaram. 

Extension  of  Enlistment  (USN)  (Execute) 

X 

Part  1 .  Chapter  2 
DMRSMAN 

Submit  NAVPERS  1070/621  to 
NAVPERSCOM  (NPC-312G) 

Extension  of  Enlistment  (EREN)  (USNR) 
(Execute) 

X 

Part  1 .  Chapter  2 
DMRSMAN 

Submit  NAVPERS  1070/621  to 
NAVPERSCOM  (NPC-312G) 

Extension  of  Reserve  Active  Duty  Obligation 
(RADO)  (USNR)  (EXECUTE) 

X 

Part  1.  Chapter  2 
DMRSMAN 

Submit  NAVPERS  1070/622  to 
NAVPERSCOM  .NPC-312G. 
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HDVRMAN 
01  MAR  99 


ACTION 

REFERENCE 

REMARKS 

D 

F 

L 

M 

DJMS  PTG 

EVENT 

M 

O 

E 

E 

(unless  otherwise  stated) 

R 

R 

T 

S 

S 

M 

T 

S 

E 

A 

S 

R 

G 

D 

S 

E 

Extension  of  Enlistment  (USN)  (Becomes 

X 

Part  1 .  Chapter  2 

ooerative) 

DMRSMAN 

Extension  of  Enlistment  (EREN)  (USNR) 

X 

Part  1 .  Chapter  2 

(Becomes  operative) 

DMRSMAN 

Extension  of  Reserve  Active  Duty  Obligation 

X 

Part  1 .  Chapter  2 

(RADO)  (USNR)  (Becomes  operative) 

DMRSMAN 

Extension  of  Enlistment  (USN)  (Cancelled) 

X 

Part  1 .  Chapter  2 

Submit  NAVPERS  1070/621  to 

DMRSMAN 

NAVPERSCOM  (NPC-312G) 

Extension  of  Enlistment  (EREN)  (USNR) 

X 

Part  1 .  Chapter  2 

Submit  NAVPERS  1070/621  to 

(Cancelled) 

DMRSMAN 

NAVPERSCOM  (NPC-312G) 

Extension  of  Reserve  Active  Duty  Obligation 

X 

Part  1 .  Chapter  2 

Submit  NAVPERS  1070/622  to 

(RADO)  (USNR)  (Cancelled) 

DMRSMAN 

NAVPERSCOM  (NPC-312G) 

Failed  to  Reportfor  Duty  or  Temporary  Duty 

X 

SDS  PPG  Chapter  2. 

Comply  with  MILPERSMAN 

Section  D 

1600-040  and  TRANSMAN  24.06 

DMRSMAN 

prior  to  submitting  foiled  to  report 
transaction 

Foreign  Language  Proficiency  Data. 

X 

SDS  PPG  Chapter  5, 

reporting  of 

Section  C 

DMRSMAN 

FORMAN,  reporting  or  correction  of 

X 

SDS  PPG  Chapter  4. 
Section  F 

Df.tRSMAN 

Gain  (diary),  correction  of 

X 

Part  1 ,  Chapter  4 
DMRSMAN 

Gain  (diary)  -  Erroneous  or  duplicate. 

X 

SDS  PPG  Chapter  2, 

cancellation  of 

Section  D 

DMRSMAN 

Gl  Bill  election,  correction 

X 

SDS  PPG  Chapter  5, 
Section  C 

DMRSMAN 

High  Year  Tenure,  waiver  of 

X 

OPNAVINST  1160.5 

Ltr  to  NAVPERSCOM  (NPC-814C) 

Series 

Limited  Duty  Designator,  charge 

X 

MILPERSMAN  1306-020 

Ltr  to  NAVPERSCOM  (NPC  821 ) 

Loss  (diary),  correction  of 

X 

Part  1 .  Chapter  4 

SDS  PPG  Chapter  3. 
Section  E 

DMRSMAN 

Loss  (diary)  -  Erroneous  or  duplicate. 

X 

Part  1 .  Chapter  4 

cancellation  of 

DMRSMAN 

Lost  Time  Adiustment  (UA) 

X 

Part  1 .  Chapter  2 

NAVPERS  1070/606 

Lost  Time  Adiustment  (Confinement' 

X 

Part  7.  Chanter  5 

NAVPERS  1070/607 
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EDVRMAN 
01  MAR  m 


ACTION 

REFERENCE 

REMARKS 

D 

F 

L 

M 

DJMS  PTG 

EVENT 

M 

O 

E 

E 

(unieee  othenwise  stated) 

R 

R 

T 

s 

S 

M 

T 

S 

E 

A 

s 

R 

Q 

D 

S 

E 

Military  Spouse  Data,  reporting  of 

X 

SDS  PPG  Chapter  5 

Section  C 

DMRSMAN 

Miscellaneous  change  (diary),  correction  of 

X 

SDS  PPG  Chapter  5. 
Section  B 

DMRSMAN 

Missing  (In  action,  etc) 

X 

X 

MILSPERSMAN  1770-020 
SDS  PPG  Chapter  3. 
Section  D 

DMRSMAN 

Missing,  return  from 

X 

X 

DMRSMAN 

New  gain  transaction  Message  to 

MILPERSMAN  1770-020 

NAVPERSCOM(NPC-621) 

Name,  change 

X 

MILPERSMAN  1000-130 

Ltrto  NAVPERSCOM(NPC-312F:. 

Name,  correction  of  EDVR 

X 

SDS  PPG  Chapter  5. 
Section  B 

DMRSMAN 

NEC.  change  (including  Tertiary.  Quaternary. 

X 

NAVPERS  18068F. 

NAVPERS  1221/1  or  complete  NEC 

Quinary) 

Section  1 

EDVRivlAN 

Discrepancy  Report 

NEC  (OA-DG).  change 

X 

SDS  PPG  Chapter  5. 
Section  B 

DMRSMAN 

Overseas  Accession  Gain 

X 

Part  1 .  Chapter  1 

DMRSMAN 

Pay  Entry  Base  Date,  correction  of 

X 

SDS  PPG  Chapter  5. 

For  lost  time  use  NAVPERS 

Section  B 

1070/606.  NAVPERS  1070/607. 

DMRSMAN 

Request  Statement  of  Service  from 
NAVPERSCOM(NPC-312E)  if 

necessary. 

Proiected  Rotation  Date,  change 

X 

ENLTRANSMAN  3.06 

Ltr  to  Assignment  Control  Authorit.' 

Race'Population  Group  Code,  change 

X 

SDS  PPG  Chapter  5. 
Section  B 

DMRSMAN 

Rate,  administrative  reduction  or 

X 

SDS  PPG  Chapter  5. 

restoration  of 

Section  B 

DMRSMAN 

Rate,  advancement  in 

X 

Part  1 .  Chapter  2 

E-1  to  E-2  advancement  (if  the 

DMRSMAN 

projected  advancement  is  not 
reflecting  on  LES):  E-2  to  E-3 
advancements  and  advancements 
other  than  those  authorized  by 

NETPDTC 

Rate,  advancement  declined 

X 

BUPERSINST  1430.16 

MSG  to  NETPDTC 
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01  M  AR  W 


EVENT 

ACTION 

REFERENCE 

DJMS  PTG 

(unleee  othervyise  stated) 

REMARKS 

D 

M 

R 

S 

S 

D 

S 

F 

0 

R 

M 

L 

E 

T 

T 

E 

R 

M 

E 

S 

S 

A 

G 

E 

Rate,  advancement  recommendation  withdrawn 

X 

BUPERSINST  1430,16 
Series 

if  prior  to  exam  results  send  MSG  to 
NETPDTC,  If  after  exam  results, 
send  MSG  to  NAVPERSCOM 
(NPC  852  /  862),  Info  copy  to 

NETPDTC  and  DFAS, 

Rate,  advancement  withheid 

X 

BUPERSINST  1430,16 
Series 

Send  MSG  to  NAVPERSCOM 
(NPC-852/862),  Info  copy  to 

NETPDTC  and  DEFAS 

Rate,  reduction  (dlscbilnarv  action) 

X 

Part  7,  Chapter  5 

NAVPERS  1070/607 

Recaiied  to  active  duty  (Voluntary/Invoiuntary) 

X 

Part  1 ,  Chapter  1 

DMRSMAN 

Submit  NAVPERS  1070/601  to 
NAVPERSCOM  (NPC-312G) 

Received  at  TAD  point 

X 

SDS  PPG,  Chapter  2, 
Section  D 

DMRSMAN 

Prepare  Reporting  Endorsement  if 
member  has  pay  record  in  possession. 

If  reportina  onboard  toauament  normal 
mannina  submit  an  ATAD  transaction. 

Received  onboard  for  duty 

X 

X 

Part  1.  Chapter  4 
DMRSMAN 

Reporting  Endorsement 

Received  onboard  for  temporary  duty 

X 

X 

Part  1 ,  Chapter  4 
DMRSMAN 

Reporting  Endorsement 

Reeniistment,  immediate 

X 

X 

Part  1 ,  Chapter  2 
DMRSMAN 

Submit  NAVPERS  1070/601  to 
NAVPERSCOM  (NPC-312G) 

Reieased  to  inactive  duty 

X 

X 

Part  1 ,  Chapter  3 
DMRSMAN 

Detaching  Endorsement 

Reservist  first  reports  for  extended  active  duty 

X 

X 

Part  1 ,  Chapter  1 

DMRSMAN 

Reporting  Endorsement 

Submit  NAVPERS  1070/622  to 
NAVPERSCOM  (NPC-312) 

Reservist  reports  for  AT  (Formerly  known  as 
ACDUTRA) 

No  MAPMIS  action 

Reservistfirst  reports  for  Active  Duty  for 

Speciai  Work  (ADSW) 

X 

X 

Part  1.  Chapter  1 

DMRSMAN 

Reporting  Endorsement 

Submit  NAVPERS  1070/622  to 
NAVPERSCOM  (NPC-3 13) 

Retained  Beyond  EAOS  (invoiuntary 

Extension  bySECNAV) 

X 

Part  1 ,  Chapter  2 
MILPERSMAN  1050155 

No  MAPMIS  action, 

NAVPERSCOM  will  nodfy  DFAS, 

Retained  Beyond  EAOS  (for  Convenience  of 
Government  and  for  essentiai  service) 

X 

Part  1 ,  Chapter  2 
MILPERSMAN  1050155 

Military  Pay  Order,  NAVPERS 

1070/613 

Return  to  active  duty  or  canceiiadon  of  an 
administrative  drop  from  Navy  strength 
accounts 

X 

SDS  PPG  Chapter  2, 
Section  D 

DMRSMAN 

Llrl'.'NAVPEFiivvM'NF'v-li'IC" _ 
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tDVRMAN 
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ACTION 

REFERENCE 

REMARKS 

D 

F 

L 

M 

DJMS  PTG 

EVENT 

M 

O 

E 

E 

(unless  othereise  stated) 

R 

R 

T 

s 

S 

M 

T 

s 

E 

A 

S 

R 

G 

D 

S 

E 

Security  data,  change 

X 

X 

EDVRMAN 

Forward  OPNAViNST  5510/413, 

Personnel  Security  Action  Request,  to 
Director,  Department  of  the  Navy 

Centrai  Adjudication  Faciiity 
(DON  CAF)  with  a  copy  of  current 

OPNAV  5520/20,  Certificate  of 

Personnei  Security  investigation, 

Ciearance  and  Access  to  correct 

security  data. 

Sex  code,  correction  of  EDVR 

X 

SDS  PPG  Chapter  5, 
Section  B 

DMRSMAN 

Shore  Duty  Commencement  Date,  chance 

X 

ENLTRANSMAN  3,162 

Ltr  to  NAVPERSCOM  (NPC-451  Di 

SSN,  change 

X 

MILPERSMAN 

1000-060 

Ltr  to  NAVPERSCOM  (NPC-324F) 

SSN,  correction  of  EDVR 

X 

EDVRMAN 

Submit  SSN  correction  to 

NAVPERSCOM  i:NPC-312F)  aiong 
with  a  certified  copy  of  sociai  security 
card  issued  by  Sociai  Security 

Administration, 

Speciai  category  code,  change 

X 

ENLTRANSMAN  24 

Ltr  to  NRPC  Code  30  or  appropriate 
NAVPERSCOM  Code 

Speciai  Duty  Assignment  Pay 

X 

Part  1 ,  Chapter  8 

or  change 

DMRSMAN 

Speciai  Program  indicator  (SPi) 

X 

EDVRMAN 

Ltr  to  NAVPERSCOM  (NPC-91 3) 

■  TAR) 

Ltr  to  NAVPERSCOM  (NPC-4010) 

■  ADSvV. 

Submarine  service,  change  type  of 

X 

SDS  PPG  Chapter  5, 
Section  B 

DMRSMAN 

Terminated  appointment  as  an  officer  or  officer 

Part  1 ,  Chapter  2 

No  MAPMiS  action. 

candidate  as  NAVCAD,  AOC,  OC,  Navai 

NAVPERSCOM  wiii  gain  member  on 

Academy  MiDN,  NROTC  orOCAR 

EDVR 

Terminated  appointment  as  a  temporary  officer 

X 

Part  1 ,  Chapter  2 

or  officer  candidate  in  the  Army,  Air  Force,  or 
Coast  Guard  Academies  and  reverted  to 
eniisted  status. 

DMRSMAN 

Time  in  Rate,  correction  of 

X 

EDVRMAN 

Ltr  to  NAVPERSCOM  (NPC-312G) 
with  substantiating  paperwork  (i,e,, 

DD4,  pages  4  and  9) 

Transferred  from  TAD  Point 

X 

X 

Part  1 ,  Chapter  4 

Prepare  Detaching  Endorsement  if 

DMRSMAN 

member  has  pay  record  in  possession. 

If  member  vyas  onboard  toauoment  normal 
m,innino  submit  a  DTAD  transaction. 

Transferred  PCS  TEMPI' _ 

P:irt1.Ci-i:ctei4 _ 

15-6 


94 


HDVRMAN 
01  M.VROO 


ACTION 

REFERENCE 

REMARKS 

D 

F 

L 

M 

DJMS  PTG 

EVENT 

M 

O 

E 

E 

(unless  otherwise  stated) 

R 

R 

T 

S 

S 

M 

T 

s 

E 

A 

S 

R 

G 

D 

E 

S 

Transferred  to  Fleet  Reserve  or  Retired  List 

X 

Part  1 ,  Chapter  3 

Detaching  Endorsement 

X 

DMRSMAN 

Unauthorized  Absence 

X 

Part  1 .  Charter  2 

NAVPERS  1070..’60e 

Watch  Quaiifications:  estabiishment.  change. 

X 

DMRSMAN 

or  removai  of 

When  in  doubt,  forward  copy  of  all  related  documents  with  letter  explaining  MAPMIS  problem  to: 

1 )  NAVPERSCOM  (NPC-3)  for  all  pay-related  items. 

2)  NAVPERSCOM  (NPC-4)  for  distribution  related  items 

Note;  This  Decision  Logic  Table  includes  transactions/events  that  affect  MAPMIS  data  not  listed  on  the  EDVR. 
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APPENDIX  B  COMMON  ASSOCIATIONS  LIST 


Category 

Examples 

A  is  a  physical  part  of  B 

Memory-Computer 

A  is  a  logical  part  of  B 

T-RatingSpeeification-Report 

T-RatingSpeeification-Report 

Squadron- AirWing 

EDVRFileltem-EDVR/EDVRUpdate 

AMDEileItem-AMD(NTMPS)/AMD 

NECAwardDateltem-NITRAS 

ManpowerDatabase-AMO’sDatabase 

Report-T -RatingCaleulations 

EDVRReeeipt-EDVRUpdate 

EDVRUpdate-EDVR 

T -RatingCaleulations-ED  VR 

T -RatingC  alculations- AMD 

T -RatingC  alculations-NEC  AwardDate 

AMD  V  erifieation-ED  VRUpdate 

AMD  V  erific  ation- AMD 

AMD  V  erification-T -RatingCaleulations 

NECDateVerification-T- 

RatingCalculations 

NECDateVerification-ED  VRUpdate 

EileArchival-ED  VRUpdate 

Notifieation-ED  VRUpdate 

Notification-T-RatingCalculations 

ReportGeneration-T-RatingCalculation 

OutputE  orwarding-T-RatingCaleulations 

T -RatePoliey-T-RateCaleulations 
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Category 

Examples 

NECCatalog-NECManual 

WorkCenterCatalog-AMOsDatabase 

AreaCatalog-AMOsDatabase 

A  is  physically  contained  in/on  B 

Computer-WingMOsOffiee 

Report-Computer 

T-RatingSpeeification-Computer 

T-RatingDeseription-Computer 

A  is  logically  contained  in  B 

T -RatingSpeeification-T-RatePolicy 

T -RatingDeseription-T -RatePolicy 

Squadron- AirWing 

EDVRFileltem-EDVR 

AMDE  ileltem- AMD 

NECAwardDate-NITRAS(or  NTMPS) 

ManpowerDatabase-WingMOsDatabase 

ManpowerDatabase-AMO’sDatabase 

Report-T -RatingCalculations 

PC-EDVR-Computer 

WingMO-AirWing 

EDVRUpdate-Eile(or  EDVR) 

NECDateV  erfication-T  - 

RatingCalcuations 

AMD  V  erifieation-T -RatingCaleulations 

T-RatingCalculations-ReportGeneration 

NECCatalog-AMOsDatabase 

WorkCenterCatalog-AMOsDatabase 

AreaCalculation-AMOsDatabase 

AMOsDatabase-Computer 

WingMOsDatabase-Computer 
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Category 

Examples 

NECDescription-NECCatalog 

WorkcenterDescripti-WorkcenterCatalog 

AreaDescription-AreaCatalog 

A  is  a  description  for  B 

NECDescription-NEC 

W  orkc  enterDescription- W  orkc  enter 

AreaDescription-Area 

A  is  a  line  item  of  a  transaction  or  report  B 

T -RatingC  alculations-Report 

EDVREileltem-EDVR 

AMDE  ileltem- AMO 

NECAwardDateItem-NITRAS(or 

NTMPS) 

A  is 

known/logged/recorded/reported/captured 

inB 

Report-ReportGeneration 

T-RatingSpecification-R-RatePolicy 

T -RatingDescription-T -RatePolicy 

EDVREileltem-EDVR 

ED  VRE  ileltem-ED  VRElpdate 

ED  VRE  ileltem-T-RatingCalculations 

ED  VRE  ileltem-ReportGeneration 

ED  VRE  ileltem-Report 

EDVREileltem-AMOsDatabase 

AMDE  ileltem- AMD 

AMDE  ileltem- AMD  V  erific  ation 

AMDE  ileltem-T -RatingCalculations 

AMDE  ileltem-T -RatingCalculations 

AMDE  ileltem-ReportGeneration 

AMDE  ileltem-Report 

AMDEileltem-AMOsDatabase 

NECAwardDate-NITRAS(or  NTMPS) 
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Category 

Examples 

NECAwardDate-AMOsDatabase 

NECAwardDate-EPMAC 

NECAwardDate-PersDiv(ServieeReeord) 

NEC AwardDate-T-Rating  Caleulations 

NECAwardDate-NECDateVerification 

NECAwardDate-ReportGeneration 

NEC  AwardDate-OutputE  orwarding 

A  is  a  member  of  B 

AMO-Squadron 

WingMO-AirWing 

A  is  an  organizational  sub-unit  of  B 

Squadron- AirWing 

PersonnelDivision-Squadron 

MaintenaneeDept-Squadron 

A  uses  or  manages  B 

AMO-AMO’sDatabase 

AMO-EDVR 

AMO-AMD 

AMO-NECAwardDate 

AMO-Computer 

AMO-Report 

AMO-EDVREileltem 

AMO-AMDEileltem 

AMO-ManpowerDatabase 

AMO-PC-EDVR 

AMO-EDVRReeeipt 

AMO-EDVRUpdate 

AMO-T-RatingCaleulations 

AMO- AMD  V  erifieation 

AMO-NECDateV  erifieation 

AMO-E  ileArehival 
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Category 

Examples 

AMO-Notifieation 

AMO-ReportGeneration 

AMO-OutputForwarding 

AMO-T-RatePoliey 

AMO-WorkCenterCatalog 

AMO-CSEC 

AMO-EDVRUsersManual 

WingMO-Computer 

WingMO-Report 

WingMO-T-RatePoliey 

WingMO-AMO 

WingMO-ManpowerDatabase 

WingMO-Notifieation 

WingMO-OutputEorwarding 

WingMO-WingMOsDatabase 

A  communicates  with  B 

AMO-WingMO 

AMO-PersonnelDivision 

AMO-ManpowerDatabase 

AMO-WingMOsOffice 

AMO-EPMAC 

AMO-MaintenanceDepartment 

AMO-NTMPS(in  Pensaeola) 

WingMO-AirWing 

WingMO-Squadron 

WingMO-WingMOsOffiee 

WingMO-ManpowerDatabase 

A  is  related  to  transaetion 

WingMO-Report 

WingMO-Notifieation 
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Category 

Examples 

AMO-ReportGeneration 

AMO-EDVRReceipt 

AMO-EDVRUpdate 

AMO-Report 

AMO-T-RatingCalculations 

AMO- AMD  V  erifieation 

AMO-NECDateVerifieation 

AMO-E  ileArchival 

AMO-Notification 

AMO-OutputEorwarding 

A  is  a  transaction  related  to  another 
transaction  B 

EDVRReeeipt-EDVRUpdate 

T -RatingC  alculations-ED  VRUpdate 

T -RatingC  alculations- AMD  V  erifieation 

T -RatingC  alculations- 

NECD  ate  V  erific  ation 

EileArchival-ED  VRUpdate 

Notifieation-ED  VRUpdate 

Notifieation-AMDVerification 

Notifieation-NECDateVerification 

Notifieation-T-RatingCalculations 

Notification-ReportGeneration 

Notifieation-OutputEorwarding 

Notification-EDVRReeeipt 

A  is  next  to  B 

AMO-Computer 

AMO-ManpowerDatabase 

AMO-PC-EDVR 

AMO-PersonnelDivision 

AMO-EDVR 
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Category 

Examples 

AMO-AMD 

AMO-OPNAV1000.16 

AMO-EDVRUsersManual 

AMO-CSEC 

AMO-NECManual 

WingMO-AirWing 

WingMO-Computer 

WingMO-ManpowerDatabase 

WingMO-OPNAV  1000.16 

Squadron-Squadron 

A  is  owned  by  B 

Report-AMO 

Squadron- AirWing 

PC-EDVR-EPMAC 

PersonnelDivision-Squadron 

MaintenanceDepartment-Squadron 

ReportGeneration-AMO 

OutputE  orwarding-AMO 

T -RatePolicy- W  ingMO 

EDVR-EPMAC 

AMD-NTMPS 

NITRAS-NTMPS 

ManpowerDatabase-AMO 

ManpowerDatabase-WingMO 
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APPENDIX  C 


CONCEPT  ASSOCIATION  DIAGRAMS 


A  is  a  Logical  Part  of  B 


"Contained-in" 
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A  is  Logically  Contained  in  B 


"Logically-in" 
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A  is  Physically  Contained  in  B 


1  11  1 


1  11  1 


"Housed-in" 
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A  is  a  Description  For  B 
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A  is  a  Line  Item  of  Transaction  or 

Report  B 


"Contained-in" 
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A  is  Known/Logged/Recorded/ 
Reported/Captured  in  B 


Report 

1  1 

Rypu[  lGy[  midliui  i 

1 

1 


1 


T-RatingSpecification 

1 

T-RatePolicy 

1 

* 

T-RateDescription  — 


■4v 


1 


1 


EDVRFileltem 

1 

EDVR 

* 

*  * 


AMD 


1 


1 


Manpowe 

_ f 

(rDaiabas 

EDVRUpdate 

1 

AM  DVerifi  cation 


1 


I 

AMDFileltem 

* 

* 


1 


_ 

-T-RatingC 

_ 

alculations 

— 

— 

* 


"Captured-on"  or  "Logs-completed-on" 


no 


A  is  a  Member  of  B 


"Member-of 
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A  is  an  Organizational  Sub-Unit  of  B 


PersonnelDivision 


"Subunit-of" 
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Computer 


A  Uses  or  Manages  B 


manages 

1  -KaterOlicv 

vVlllUIVl'U 

jutPutForwardin  i 


EDVRUpdate  I 


EDVRReceipt  I 


Manoowe 

'rDaiabas  i 

FileArchival 

e 

_ _ 

ll - 1 

lEDVRFileltem 


AMDFileltem 


CSEC 

uses  1 

WorkCetiterCatj 

0^ 

g 

uses 

_ 

"Uses"  or  "Manages" 


A  Communicates  with  B 


"Communicates-with" 
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A  Is  Related  To  Transaction  B 


5 


A  is  a  Transaction  Related  To 
Another  Transaction  B 
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A  is  Next 


1  1 


"Next-to" 


7 


AirWing 


A  is  Owned  By  B 


"Owned-by" 

"Responsible-for" 

"Owns" 
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APPENDIX  D  CONCEPT  MODEL  ATTRIBUTE  DISCUSSION 


EDVRReceipt 

date  -  When  the  new  EDVR  is  reeeived  the  date  will  be 
reeorded. 

uic  -  Identifieation  of  the  Command  to  whieh  the  new 
EDVR  belongs. 

EDVRUpdate 

date  -  In  order  to  eompare  the  new  EDVR  to  the  on- 
hand  EDVR,  the  date  will  be  required. 

time  -  In  order  to  list  when  the  update  was  completely 
proeessed,  the  time  field  should  be  known. 

UIC  -  In  order  to  eonfirm  that  the  eorreet  EDVR  is 
reeeived  the  UIC  will  need  to  be  known. 

Notification 

date  -  In  order  to  determine  when  notifieation  was 
delivered  the  date  needs  to  be  known. 

time  -  In  order  to  determine  when  notifieation  was 
delivered,  the  date  needs  to  be  known. 

ManpowerDatabase 

area  -  In  order  to  eomplete  the  T-Rating  ealeulation 
report,  the  area  of  work  needs  to  be  known. 

experience  -  In  order  to  eomplete  the  T-Rating 
ealeulation,  the  amount  of  experienee  needs  to  be 
known. 

AMO 

rank  -  In  order  to  properly  list  the  author  on  the  report 
submission,  the  rank  needs  to  be  known. 

name  -  In  order  to  properly  list  the  author  on  the  report 
submission,  the  name  needs  to  be  known. 

command  -  In  order  to  properly  list  the  author  on  the 
report  submission,  the  eommand  needs  to  be  known. 

UIC  -  In  order  to  properly  list  the  author  on  the  report 
submission,  the  UIC  needs  to  be  known. 

phone  -  In  order  to  list  author  eontaet  information,  the 
phone  number  is  needed. 

e-mail  -  In  order  to  list  author  eontaet  e-mail  address. 
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WingMO 

rank  -  In  order  to  properly  submit  report,  rank  needs  to 
be  known. 

name  -  In  order  to  properly  submit  report,  name  needs 
to  be  known. 

command  -  In  order  to  properly  submit  report, 
eommand  needs  to  be  known. 

UIC  -  In  order  to  properly  submit  report,  UIC  needs  to 
be  known. 

phone  -  In  order  to  list  contaet  information,  the  phone 
number  is  needed. 

e-mail  -  In  order  to  list  contaet  e-mail  address. 

Report 

date  -  In  order  to  establish  date  of  submission,  date 
needs  to  be  known. 

time  -  In  order  to  establish  time  of  submission,  time 
needs  to  be  known. 

UIC  -  In  order  to  establish  command  submitting  report 
UIC  needs  to  be  known. 

command  -  In  order  to  list  alphanumeric  designation  of 
command,  command  needs  to  be  known. 

submitted  by  -  In  order  to  list  name  of  author,  name 
needs  to  be  known. 

EDVR  Date  -  In  order  to  establish  baseline  of  current 
EDVR,  EDVR  date  needs  to  be  known. 

AMD  Date  -  In  order  to  establish  baseline  of  current 
AMD,  AMD  date  needs  to  be  known. 
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EDVRFileltem 

UIC  -  In  order  to  identify  the  eommand,  UlC  needs  to 
be  known. 

rate  -  In  order  to  identify  the  rate  of  the  member  filling 
the  billet,  rate  needs  to  be  known. 

COB  -  This  will  be  used  for  Manning  Rates  subsequent 
to  T-Rate 

EDA/L  -  In  order  to  provide  report  fields  per  the  Wing 
MO’s  request. 

NECl  -  The  primary  NEC  whieh  the  member  has  been 
ordered  into  the  command  with. 

NEC2  -  The  secondary  NEC  which  the  member  has 
been  ordered  into  the  command  with. 

A/C  T/M/S  -  Aircraft  Type/Model/Series 

Area  -  In  order  to  complete  the  T-Rating  calculation 
report,  the  area  of  work  needs  to  be  known. 

AMDFileltem 

UIC  -  In  order  to  identify  the  command,  UIC  needs  to 
be  known. 

BSC  -  In  order  to  determine  specific  billets,  the  BSC  is 
needed. 

BNEC  -  In  order  to  determine  T-Rating,  BNEC  is 
needed  to  determine  who  has  been  assigned  into  which 
billet. 

BRate  -  In  order  determine  the  billet  rate,  the  BRate 
needs  to  be  known. 
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NECDateV  erificationitem 

date  -  In  order  to  determine  when  the  verifieation  was 
processed  the  date  is  needed. 

time  -  In  order  to  determine  the  time  when  the 
verification  process  was  completed  the  time  is  needed. 

name  -  In  order  to  correctly  identify  the  member  for 
which  the  verification  is  being  done  the  member’s  name 
is  needed. 

rate  -  In  order  to  correctly  identify  the  member  for 
which  the  verification  is  being  done  the  member’s  rate  is 
needed. 

UIC  -  In  order  to  correctly  identify  the  command  to 
which  the  member  is  attached  the  UIC  is  needed. 

SSN  -  In  order  to  correctly  identify  the  member  for 
which  the  verification  is  being  done  the  member’s  SSN 
is  needed. 

NECl  -  In  order  to  verify  correctly  the  member’s 
experience  level  the  NEC  is  needed. 

NEC2  -  In  order  to  verify  correctly  the  member’s 
experience  level  the  NEC  is  needed. 

Date  Awarded  -  In  order  to  correctly  determine  the 
member’s  T-Rating  the  Date  Awarded  is  needed. 

Experience  -  In  order  to  correctly  determine  the 
member’s  T-Rating  the  Experience  needs  to  be  correctly 
determined. 

EDVR 

date  -  When  the  new  EDVR  is  received  the  date  will  be 
recorded  for  comparison  purposes. 

uic  -  Identification  of  the  Command  to  which  the  new 
EDVR  belongs  to  for  comparison  purposes. 

AMD 

date  -  When  the  new  EDVR  is  received  the  date  will  be 
recorded. 

uic  -  Identification  of  the  Command  to  which  the  new 
EDVR  belongs. 
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APPENDIX  E  USERS’  MANUAL 


PROMETHEUS  MANPOWER  MANAGEMENT  SOLUTION 
Naval  Postgraduate  School,  Monterey  CA,  93943-5001 


RcmetejsMIVB 

User  Guide 
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Naval  Postgraduate  School  Database  Implementation 

Prometheus  Manpower  Management 
Solution  (PMMS)  User  Guide 


LCDR  Daniel  P.  Granados,  USN 
LT  Kreg  L.  KeUy,  USN 
©  Prometheus  Thesis  Research  Team 
Naval  Postgraduate  School,  Monterey  CA,  93943-5001 
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Setup 

Introduction 


Thank  you  for  using  the  Prometheus  Manpower  Management  Solution  (PMMS) 
electronie  database.  PMMS  was  created  by  LCDR  Daniel  P.  Granados  and  LT 
Kreg  L.  Kelly  as  a  thesis  research  project  in  manpower  management  at  the  Naval 
Postgraduate  School  in  Monterey,  California. 

In  order  to  address  the  challenges  of  managing  personnel,  training,  and  readiness  in 
aviation  squadrons,  the  functions  and  responsibilities  of  a  manpower  manager  were 
developed  and  assigned  to  one  officer,  the  Assistant  Maintenance  Officer  (AMO).  For 
most  Assistant  Maintenance  Officers,  it  is  said  that  the  manpower  management  function 
is  the  most  complex  and  critical  aspect  of  their  job. 

Assistant  Maintenance  Officers  currently  use  paper  copies  of  reports  such  as  the  Enlisted 
Distribution  and  Verification  Report  (EDVR)  and  the  Squadron  Manning  Document 
(SQMD)  or  Activity  Manning  Document  (AMD)  to  reconcile  manning  issues  and 
manage  their  manpower  databases.  Both  reports  are  published  regularly.  The  EDVR  is 
published  monthly,  while  the  SQMD/ AMD  are  published  upon  completion  of  an  activity 
Aviation  Manpower  Requirements  Determination  (for  SQMD)  or  Shore  Manpower 
Requirements  Determination  (for  AMD),  or  as  major  changes  occur. 

The  PMMS  application  attempts  to  address  the  specific  functions  of  manpower 
management  by  automating  the  reconciliation  process  between  the  EDVR  and  the 
SQMD/AMD — allowing  the  AMO  to  match  bodies  assigned  to  the  billets  assigned 
within  a  squadron.  The  solution  capitalizes  on  the  use  of  existing  commercial-off-the- 
shelf  (COTS)  technologies,  existing  manpower  databases  maintained  within  the  Navy, 
and  process  automation  of  what  is  traditionally  completed  through  use  of  paper  and  pen. 

PMMS  is  a  prototype  application  and  therefore  only  addresses  a  portion  of  the  overall 
responsibilities  of  the  manpower  manager.  PMMS  functionality  is  currently  focused  on 
the  aviation  side  of  naval  forces  afloat  and  ashore.  We  hope  that  PMMS  and  future 
editions  of  this  product  will  prove  to  be  powerful  business  tools,  helping  manpower 
managers  reduce  paperwork  redundancy,  save  valuable  time  and  resources,  and 
effortlessly  manage  and  maintain  valuable  data  about  their  personnel. 


System  Requirements 

The  PMMS  application  is  a  Microsoft©  .NET  stand  alone  application  that 
interfaces  with  a  Microsoft  Access®  Database.  To  use  PMMS,  it  is  strongly 
recommended  that  your  computer  meet  the  following  minimum  requirements: 

•  PC  with  300  megahertz  or  higher  processor  clock  speed  recommended;  233 
MHz  minimum  required  (single  or  dual  processor  system);  Intel 
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Pentium/Celeron  family,  or  AMD  K6/Athlon/Duron  family,  or  compatible 
processor  reeommended 

•  128  megabytes  (MB)  of  RAM  or  higher  reeommended  (64  MB  minimum 
supported;  may  limit  performanee  and  some  features) 

•  260  megabytes  (MB)  of  available  hard  disk  space* 

•  Super  VGA  (800  x  600)  or  higher-resolution  video  adapter  and  monitor 

•  CD-ROM  or  DVD  drive 

•  Keyboard  and  Microsoft  Mouse  or  eompatible  pointing  device 

•  Microsoft®  Windows  2000,  XP,  .NET  Family  Operating  Systems  or  later. 

•  Mierosoft©  .NET  Framework  with  Serviee  Pack  2  installed. 


Microsoft©  Jet  4.0  Database  Engine  and  Microsoft  Data  Access  Components  2.6 
or  greater  installed.  These  components  are  standard  in  Windows  2000  platforms 
and  greater. 

*Prometheus  Applieation  requires  4.7  MB  of  available  hard  disk  space.  E-Pro 
Alpha.mdb  ships  at  8.3  kilobytes  (KB).  The  size  of  the  database  file  (.mdb  file) 
eannot  be  determined  and  varies  at  any  given  time  as  the  user  adds  on  to  it.  Size 
requirements  noted  above  reflect  the  loeal  eopy  of  all  source  files,  legacy  files  and 
datum,  and  archived  images  used  to  create  this  project. 


Installation  Instructions 

Option  1:  PMMS  is  a  self-contained  Mierosoft©  .NET  stand  alone  application 
and  database  solution  that  can  be  aecessed  from  any  physical  medium  with 
read/write  aeeess.  Simply  double-cliek  the  PMMS  icon  to  launch  the  application 
from  its  root  directory.  NOTE:  if  using  PMMS  in  this  manner,  the  database  file 
E-Pro  Alpha.mdb  must  be  in  the  treed  directory  as  follows  “. .  .\Database  Files” 

Option  2:  setup. msi  file  is  located  in  the  root  direetory  of  the  distributed  PMMS 
program.  Double-elick  the  setup. msi  file  in  order  to  start  the  installation  process. 
Installation  can  be  done  to  any  physical  medium  that  the  user  has  read/write 
access  to  (i.e.  zip  disks,  CD-RW).  It  is  highly  recommended  that  the  user  install 
the  PMMS  program  in  its  default  loeation  in  order  to  ensure  maximum 
operability.  NOTE:  Prometheus  application  installs  several  eore  application  files 
that  are  required  for  proper  operation  of  the  program.  These  files  are  loeated  in 
predetermined  loeations  and  can  not  be  moved  after  installation.  Movement  or 
modification  of  any  of  the  core  applieation  files  will  cause  the  program  to  fail 
since  the  program  has  been  written  to  look  in  predetermined  file  loeations  in  order 
to  perform  its  functions. 
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Uninstalling  the  Software 

If  PMMS  was  installed  using  the  setup.msi  file  provided  with  the  distributed 
PMMS  program,  uninstalling  the  software  may  be  aecomplished  via  two  methods; 

1 .  From  the  Start  Menu  >  All  Programs  >  PMMS  Beta  1  Folder,  elick  Uninstall 
Prometheus. 

2.  From  the  Control  Panel,  cliek  Add  or  Remove  Programs.  Seroll  and  seleet 
Prometheus  Manpower  Management  Solution  vl.O.lB,  and  cliek 
Change/Remove  button  to  uninstall. 

Warning;  Uninstalling  Prometheus  will  delete  the  database  file  E-Pro 
Alpha.mdb.  Deleting  this  database  file  will  permanently  remove  all  stored  data 
and  will  be  unrecoverable  without  a  prior  backup.  The  current  version  of 
Prometheus  does  not  include  a  backup  utility  at  this  time.  To  backup  any  data 
files  prior  to  uninstallating  Prometheus,  the  user  must  copy  the  file  to  a  secure 
location  on  a  separate  disk. 
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User  Interface  Familiarity 

This  section  will  introduce  you  to  the  Graphical  User  Interface  (GUI),  which  is  the 
primary  means  for  interacting  with  the  PMMS  application. 


About  the  User(s) 

The  PMMS  database  has  been  designed  for  multiple  users,  providing  a  wide  range 
of  capabilities  for  each  particular  user.  Each  type  of  user  interfaces  with  the 
appropriate  form  type  to  complete  required  tasking.  Currently,  the  PMMS  GUI 
supports  only  the  role  of  the  AMO.  Later  versions  of  PMMS  will  expand  the 
application  interface  into  user  groups  and  their  appropriate  functionality 
requirements. 


Introducing  the  User  Interface 

When  you  first  open  (initiate  a  session  with  the  database)  PMMS,  a  main  window 
is  presented  for  input  as  shown  below  in  Figure  26. 


Figure  26.  PMMS  Main  Window 


The  Main  Menu  is  your  starting  point  from  where  you  can  launch  the  desired 
application  functions  (forms  and  reports)  that  will  help  you  manage  your 
personnel.  The  Main  Menu  initiates  the  following  Prometheus  Core  Functions, 
which  are  pictured  below  as  Figures  27  through  30.  For  extensive  information 
about  each  core  function,  see  Chapter  3,  Managing  Basic  Features. 

1 .  Import  AMD  &  EDVR  Text  Files 
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Figure  27.  Import  Wizard 


2.  Assign  Billet  Sequenee  Code  (BSC)  to  SAILOR  reeord. 


I  Prometheus  -  Assign  BSC  to  Sailor  Editor 


CuKent  Sailor  Info: 
Last  Name 
[Abet 


I  [Brent 


Rate  PNEC  SNEC 
“jAMAN  “[0842  j 


Show  Available  BSCs  by  Sailor's: 

RateP.E.AZS)  r  Rating  (I.E.  A2]  r  PNEC  Assign  BSC  to 

Sailor 


All  Sailors  Assi^ed 
to  BSC 


ReLoad  j  Update  j  CancelAII  | 


Figure  28.  BSC  Form 

3.  Maintain  Sailor  Personal  &  Professional  Data. 
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^  Prometheus  -  Sailor's  Datum  Editor  (Single  Record  View) 


ElB 


PiintAD  Sailor  Datun 


% 


Print  Selected  Datum 


View  All  Sailors 


Add  New  Sailor 


Delete  Cuiiet^  Sailer 


Caicsl  Last  Change 


Cartel  AD  Changes 


Aber,  Brent , 


Professional  Datum  |  Notes  | 


Home  Address  ^ 

Dtii  Name  ^ 

Slate  Code  ^ 

ZipCode  r 


SaBor  Record  Navigation  Buttons; 


1  Berthing  |  Depe 

1  Last  Name 

|Aber 

Home  Phone  |(4[)g| 

First  Name 

iBrent 

Work  Phone  | 

Middle  Name 

|i 

Fax  1 - 

Nirdc-name 

1 

Hager  | 

Cell  Phone  | 

Home  Email  ^ 
Work  Email  ^ 


© 


Figure  29.  Personal  &  Professional  Data 
4.  View,  Modify  &  Print  NEC  Datum. 


Figure  30.  NEC  Data  View 
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Identifying  Keys  &  Buttons 

Illustrations  and  explanations  of  the  buttons  and  controls  found  throughout  the 
PMMS  application  are  provided  below: 

Prometheus  Main  Application  Window 

Initiates  the  opening  of  the  Single  Sailor  Record  Editor  and 
allows  the  user  to  modify  sailor  data  in  an  organized  and 
detailed  manner. 

Initiates  the  opening  of  the  Multiple  Sailor  Record  Editor 
and  provides  a  simple  mechanism  to  modify  numerous  and 
similar  data  in  an  efficient  manner. 

Initiates  the  opening  of  the  Assign  BSC  to  Sailor  Form. 


Initiates  the  opening  of  the  View/Print  NEC  Datum  Form. 

This  button  picture  is  also  used  with  other  function  forms  to 
print  formatted  or  selected  data. 

Form  Specific  Control  Buttons 

This  button  is  used  for  multiple  record  forms.  It  applies  all 
changes  to  data  fields  that  have  been  made  by  the  user  since  the 
last  reload/loading  of  the  data.  Note:  All  data  will  be  saved  to  the 
database. 

This  button  is  used  for  multiple  record  forms.  It  cancels  all 
changes  made  to  data  fields  that  have  been  made  by  the  user  since 
the  last  reload/loading  of  the  data.  Caution:  All  changes  will  be 
lost  when  this  process  is  initiated. 

This  button  reloads  the  data  from  the  database.  Caution: 

Any  changes  made  to  the  data  fields  will  be  lost  if  changes  were 
not  saved  previously. 

This  button  is  used  to  close  the  current  form  it  is  attached  to. 


This  button  is  used  on  the  Single  Sailor  Record  Form.  It  adds 
a  new  Sailor  Record  to  the  database. 


This  button  is  used  on  the  Single  Sailor  Record  Form,  It 

deletes  the  currently  viewed  Sailor  Record  from  the  database. 


Reload 


Close 


Add  New  Sailor 


Delete  Current  Sailor 


Multiple  Record  Editor 
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Cancel  All  Changes 


Cancel  Last  Change 


> 

Save  Changes 


This  button  is  used  on  the  Single  Sailor  Record  Form,  It 

cancels  all  changes  made  to  the  eurrently  viewed  Sailor  Reeord  & 
restores  the  original  data  from  the  database. 

This  button  is  used  on  the  Single  Sailor  Record  Form,  It 

cancels  the  last  change  made  to  the  currently  viewed  Sailor 
Record  &  restores  the  original  data  from  the  database. 

This  button  is  used  on  the  Single  Sailor  Record  Form,  It  saves 
all  changes  made  to  the  currently  viewed  Sailor  Reeord  to  the 
database. 


I  >>  j  Navigation  button.  Moves  to  the  Last  individual  record  in  the 

database. 

vdllOF  I  1.. 

I  <  I  Navigation  button.  Moves  to  the  previous  individual  record  in  the 

database  from  the  currently  viewed  record. 

..nun;;. 

j.  I  Navigation  button.  Moves  to  the  next  individual  record  in  the 

- database  from  the  currently  viewed  record. 


Navigation  button.  Moves  the  First  individual  record  in  the 
database. 


Prints  all  available  data  of  a  particular  form’s  view. 


Print  All  Sailor  Datum 
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Managing  Basic  Features 
Navigating  Forms 

To  navigate  about  the  fields  in  a  form,  the  user  has  two  options.  The  first  option 
is  to  use  the  mouse  to  elick  on  a  field  to  be  modified  and  then  enter  the 
appropriate  information.  The  seeond  option  involves  the  keyboard  only.  Simply 
press  the  <Tab>  key  and  the  cursor  will  move  to  the  next  field  for  user 
modification.  Refer  to  Navigating  Forms  above  for  more  information. 


Form  Buttons  &  Controis 

Below  are  the  controls  for  navigating  through  records  in  the  database.  Each 
record  holds  unique  information  particular  to  a  single  sailor.  The  caption 
window,  show  in  Figure  31  below  indicates  which  record  the  user  is  currently 
viewing.  Button  descriptions  are  listed  below,  following  Figure  31. 


Record;  H  I  -  1 1  T  ►  I  !►*!  of  13 


F igure  31.  Form  Navigation  Buttons 


Jll 

LiJ 

jJ 

Ll*J 


Takes  the  user  to  the  first  record  in  the  database. 

Takes  the  user  to  the  previous  record  in  the  database. 
Advances  the  user  to  the  next  record  in  the  database. 
Advances  the  user  to  the  last  record  in  the  database. 

Inserts  a  new  record  in  the  database  for  input  of  a  new  sailor. 


Using  Drop-down  Menus 

When  you  select  a  drop  down  menu  (shown  in  figure  32  below),  a  list  of  available 
options  will  be  presented  in  a  list  window  near  the  insertion  window  (shown  in 
figure  33  below). 
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Simply  enter  the  desired  input  ehoice  by  seleeting,  or  pressing  the  <Enter>  key  on 
your  keyboard  to  input  the  highlighted  data  into  the  sailor’s  database  record. 


jPaygrade  |E-4 

Figure  32.  Paygrade  Drop  Down  List 


jPaygrade 

ar 

E-3 

Fireman 

▲ 

IPriNEC 

E-4 

P.O.  3rd  Class 

r 

E-5 

P.O.  2nd  Class 

jSecNEC 

E-6 

c  7 

P.O.  1st  Class 

JFICATION  INF 

XZ~  / 

E-8 

Lnier  reity  LJincer 
Senior  Chief  P.O. 

E-9 

Master  Chief  P.O. 

▼ 

Figure  33.  Paygrade  Drop  Down  List  open 


Note:  this  screen  is  for  demonstration  purposes  only.  This  form  and  its  features 
have  been  reserved  for  future  releases  of  Prometheus. 


How  to  Create  New  Sailors 

Use  the  Insert  New  Record  Button  on  any  individual  record  form. 


How  to  Modify  Record  Information 

Changes  made  to  a  sailor’s  record  (the  information  currently  viewed  in  a 
particular  interface  window)  are  real  time.  New  inputs,  modifications,  deletions, 
etc.  are  real  time  and  automatically  affect  the  database. 


How  to  Generate  a  Report 

Reports  are  generated  automatically  from  each  form  by  pressing  the  “Print” 
button.  Once  depressed,  a  formatted  report  will  display  allowing  the  user  to 
preview  data  prior  to  actual  printing.  Later  versions  of  PMMS  will  incorporate  a 
greater  range  of  reports  and  forms  for  every  user  category  which  will  greatly 
enhance  manpower  management  productivity. 
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How  to  Print  a  Report 


Use  the  Print  Current  Report  buttons  along  side  the  type  of  report 
you  are  interested  in.  Available  reports  for  printing  can  be  seen  in 
the  Reports  menu,  Figure  3. 


How  to  View  a  Report 

Note:  Currently  every  print  action  initiates  a  print  preview  of  the 
report  requested.  Future  editions  of  Prometheus  will  incorporate  a 
specific  Preview  function. 


How  to  Email  a  Report 

Use  the  E-mail  Current  Report  button  along  side  the  type  of  report 
you  are  interested  in.  Available  reports  for  e-mailing  can  be  seen  in 
the  Reports  menu,  Figure  3.  Note:  Launching  the  E-mail  Current 
Report  button  will  launch  the  default  E-mail  client  assigned  to  your 
operating  system.  For  more  information,  see  your  system  help  files. 


How  to  use  Prometheus  Core  Functions 

Extensive  information  on  Prometheus’  Core  Functions  can  be  found  in  the 
Prometheus  Help  Library  from  within  the  application.  Here,  they  can  be  printed 
and  viewed  in  hard  copy  as  necessary. 
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USER’S  MANUAL  GLOSSARY 


BMP  file 

Button 

Email 

Email  Client 

Database 

Division 

Form 

PMMS 

GUI 

Subform 

Additional 

References 


A  Microsoft  Windows  bitmap  file  that  has  the  extension  .bmp.  A  bitmap 
file  defines  an  image  (sueh  as  the  image  of  a  seanned  sailor)  as  a  pattern 
of  dots  (pixels). 

A  eontrol  on  the  GUI  that  allows  the  user  to  easily  interaet  with  the 
PMMS.  See  Identifying  Keys  &  Buttons  for  more  information. 

Eleetronie  Mail  -  An  abbreviation  for  eleetronie  mail.  Software  that  you 
ean  use  to  eleotronieally  transmit  items  over  a  eommunieation  network. 

A  eomputer  program  designed  to  transmit  eleetronie  media  via  the 
internet. 

A  usually  large  eolleetion  of  data  organized  espeeially  for  rapid  seareh 
and  retrieval. 

Unit  of  personnel  assigned  to  the  primary  maintainer  of  the  database.  For 
all  intensive  purposes,  there  is  no  funetional  limit  to  the  size  of  the 
division,  viee  system  limitations. 

The  eustom  dialog  between  the  user  and  the  PMMS  database  via  the 
GUI.  For  an  example  and  more  information  see  Introducing  the  User 
Interface. 

Prometheus  Manpower  Management  Solution 

Graphieal  User  Interfaee.  The  window(s)  presented  to  the  user  by  the 
PMMS  for  interaetion  with  the  notebook  program. 

A  subform  is  a  form  within  a  form.  The  primary  form  is  ealled  the  main 
form,  and  the  form  within  the  form  is  ealled  the  subform.  A 
form/subform  eombination  is  often  referred  to  as  a  hierarchieal  form,  a 
master/detail  form,  or  a  parent/ehild  form.  The  main  form  and  subform  in 
this  type  of  form  are  linked  so  that  the  subform  displays  only  reeords  that 
are  related  to  the  current  reeord  in  the  main  form. 

An  extensive  glossary  of  terms  and  aeronyms  ean  be  found  in  the 
Prometheus  Help  Fibrary  from  within  the  PMMS  applieation. 
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APPENDIX  F  DOWNLOAD  THE  APPLICATION 


The  Prometheus  Application  developed  in  this  thesis  is  considered  to  be  an  open 
source  program.  It  is  intended  that  for  it  to  be  used  by  aviation  squadron  manpower 
managers.  The  URL  may  be  used  in  order  to  download  the  Prometheus  Application. 

http://librarv.nps.navv.mil/uhtbin/hvt)erion-image/27Ser)%5Fgranados%5Fkellv/Prometheus.exe 


143 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


144 


GLOSSARY 


Term 

Comments 

T-Rating 

A  rating  based  on  an  individual’s  training  level 
and  years  of  experience  in  their  current  NEC. 

NEC 

Navy  Enlisted  Classification;  refers  to  the  job 
specialty  or  rating  classification  code. 

M-Rating 

Manning  Rating  which  refers  to  the  quantity  of 
personnel  Current-On-Board  per  Billets  Assigned 
(COB/BA). 

Web-Based  Interface 

An  interface  to  allow  use  of  the  Internet  to  access 
a  centralized  database. 

TRMS 

Type-Command  Readiness  Management  System. 

PC-EDVR 

An  application  distributed  by  EPMAC  New 
Orleans,  EA  for  the  purpose  of  processing  the 
activity’s  EDVR  via  a  personal  computer. 

EPMAC 

Enlisted  Personnel  Manpower  Activity  Center; 
manages  enlisted  personnel 
assignments/qualifications  for  all  Navy  enlisted; 
New  Orleans,  EA. 

Import  EDVR 

The  act  of  bringing  in  a  more  current  EDVR  into 
the  manpower  database  utilizing  PC-EDVR 
application. 

Import  EDVR 

Description  of  the  process  of  importing  the 

EDVR. 

T-Rating  Update 

Description  of  the  process  of  calculating  and 
updating  the  new  T-Rating  after  a  new  EDVR  has 
been  received. 

Wing  MO  T-Rating  Update 

Description  of  the  Wing  MO’s  T-Rating  database 
being  updated. 

EDVR  Receipt 

The  transaction  of  being  notified  of  and  accepting 
a  new  EDVR. 

EDVR  Update 

A  new  EDVR,  which  has  not  yet  been  imported  to 
the  manpower  database  via  PC-EDVR. 

T-Rate  Policy 

The  definition  of  the  T-Rating  categories  as  set 
forth  by  the  Wing  MO. 

T-Rating  Calculations 

The  process  of  calculating  the  T-Rating. 
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Term 

Comments 

Notification 

An  e-mail  message  of  notifieation  when  a  proeess 
or  action  has  been  eompleted. 

Manpower  Database 

The  main  database  that  holds  all  manning  data  for 
the  AMO  from  which  data  for  the  T-Rating  come. 

Report 

The  report  output  of  the  T-Rating  ealeulations. 

EDVR  File  Items 

Fine  items  from  the  EDVR. 

AMD  File  Item 

Fine  items  from  the  AMD. 

NEC  Date  Verifieation  Item 

Fine  item  from  the  NEC  Date  Verifieation 

NEC  Date  Verifieation 

The  verifieation  of  the  NEC  Award  Date. 

date:  Date 

Date;  taken  from  other  source  doeuments  and 
annotated  on  doeuments  produeed  in  the  proeess. 

time:  Time 

Time;  annotated  to  aid  in  keeping  traek  of  when 
proeesses  oecur  and  are  eompleted. 

uie:  UIC 

Unit  Identifieation  Code;  a  fixed  five  digit  integer 
eode. 

title:  String 

In  a  Notifieation,  the  message  will  have  a  title  that 
details  the  type  of  aetion/proeess  that  has 
oeeurred. 

area:  String 

The  area  of  maintenanee  on  a  T/M/S  that  has  been 
assignment  to  the  enlisted  member  as  annotated 
by  the  AMO. 

experienee:  String 

The  amount  of  time  that  a  member  has  worked  in 
the  skill  area  to  whieh  the  NEC  applies.  Quantity 
may  range  from  months  to  years. 

rank:  String 

Rank  listed  in  standard  Navy  format  for  address 
purposes. 

name:  String 

For  address  purposes. 

eommand:  String 

The  eommand  designation  (i.e.  VFA-125). 

phone:  Integer 

The  telephone  number  ineluding  area  eode.  Also 
ineludes  DSN  phone  number. 

e-mail:  String 

The  e-mail  address  of  individuals  for 
oommunieation  purposes. 

submitted  by:  String 

Name  and  rank  of  offieer  submitting  report  or 
eorrespondenee. 
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Term 

Comments 

edvr  date;  Date 

Date  of  the  EDVR 

amd  date:  Date 

Date  of  the  AMD 

eob; Integer 

Current  On  Board;  quantity  of  personnel  on  board 
in  a  speeifie  eategory. 

eda/1:  Date 

Estimated  Date  of  ArrivaEEoss. 

neel; Integer 

NEC  1  of  an  individual  reeord  as  listed  in 
the  EDVR. 

nee2: Integer 

NEC  2  of  an  the  individual  reeord  to  whieh  NEC 

1  eomes  from  as  listed  in  the  EDVR. 

a/e  t/m/s:  String 

Alphanumerie  designation  of  an  aireraft 
type/model/series  (i.e.  E/A-18C) 

bse: Integer 

Billet  Sequenee  Code;  assigned  in  the  AMD  for 
eaeh  billet  listed. 

brate:  String 

Billeted  Rate;  the  rate  that  has  been  assigned  to 
the  billet  listed  in  the  AMD  under  A  RTABBR 
eolumn. 

date  awarded:  Date 

The  aetual  date  that  an  NEC  has  been  awarded  as 
verified  by  the  AMO  or  verifieation  proeess. 

T -RatingC  aleulation 

A  eoneept  of  eaeh  T-Rating  Caleulation  proeess 
that  is  initiated  by  the  AMO. 

T-RatingCalculationLineltem 

A  specific  line  item  of  the  T-Rating  Calculation. 

bnee 

Billeted  NEC  as  listed  in  the  AMD  under 

A  PNEC  column. 
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